Open eli-schwartz opened 6 months ago
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?
places where we've technically violated the ODR [...] This would ordinarily not be a problem until something like LTO comes along
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 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?
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?
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