-
Notifications
You must be signed in to change notification settings - Fork 364
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 #1810
Comments
This looks like various places where we've technically violated the ODR, naming different things the same name in different file scopes, assuming that the compilation units will not interfere with each other. This would ordinarily not be a problem until something like LTO comes along and wants to mash the compilation units together. I suspect that the solution is going to involve carefully rooting those out and changing the names to be unique. Maybe putting them in anon namespaces in their file scopes will also work? |
The thing about LTO is that it is "just" a really powerful global optimizer. An ODR violation is an ODR violation either way, and even without LTO it can produce generated code that misbehaves in difficult to detect runtime bugs. What LTO is also really good at is giving the compiler extremely good whole-program visibility for diagnostics. :) ...
I suspect you also want to verify whether they are coincidentally named the same or are supposed to be semantically the same item and the definitions fell out of sync. The DECL stuff looks suspicious. The yy* issues can be solved by teaching flex/bison to use prefixes for their internal generated code that are different per file -- such is the peril of code generators. :) |
Does anybody know of a utility that can enumerate all the ODR violations in a codebase? |
Easiest way to do that I guess is via whole-program analysis. Which is what gcc -flto does. :D |
I tried to build with the following *FLAGS to optimize the build:
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Note 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:
Originally reported downstream: https://bugs.gentoo.org/875836
Full build log: build.log
The text was updated successfully, but these errors were encountered: