-
-
Notifications
You must be signed in to change notification settings - Fork 355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build fails with LTO due to type mismatch/ODR violations #1783
Comments
Thanks for the issue report. All the examples above (which one exception for Python) appear to be from the Fortran interface. Cantera using mismatched types for integers in Fortran is something that is known (it may actually be a deliberate hack). Can you confirm that the
block is the only one remaining if you compile without Fortran support? I.e. using the |
Yeah, it does seem to show up in a lot of packages. :) Sometimes they do get fixed after my report though -- in at least one case, that involved adopting the use of Fortran 2003 "BIND(C)". I don't really understand the details very well since I don't know Fortran. :( But e.g. the GCC docs talk about it as "the" facility for ensuring interoperability between C and Fortran interfaces when producing shared libraries. Maybe that's an option here? |
Yes, as long as the build is without fortran support it is just the one error. |
Thanks for confirming! |
The warnings about All usage of this struct seems to be guarded by the |
That is a very interesting use case which does seem valuable. Another possibility from the cython side could be if they offered the ability to simply allow producing "_part1.cpp", "_part2.cpp" files when processing pyx files that produce especially large generated outputs. I would probably open a feature request if I were you. :) |
Problem description
I tried to build with the following *FLAGS to optimize the build:
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Link-Time Optimization is a massively global compiler optimization pass which is pretty handy for producing faster executables. It also has the interesting property that because the compiler does whole-program analysis using bytecode, it can save type information and perform error checks that it normally doesn’t have enough insight for. In particular, checking for ODR issues and checking function type signature mismatches.
Note that all the -Werror=* flags are used to help detect cases where the compiler tries to optimize by assuming UB cannot exist in the source code -- if it does exist, ordinarily the code would be miscompiled, and this says to make the miscompilation a fatal error.
I got this error:
Steps to reproduce
Compile with GCC.
Include the following CFLAGS / CXXFLAGS / LDFLAGS:
-flto -Werror=odr -Werror=lto-type-mismatch
System information
gcc (Gentoo 13.3.1_p20240614 p17) 13.3.1 20240614
Python 3.12.3
Attachments
Full build log of the failure: build.log
The text was updated successfully, but these errors were encountered: