https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97261
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Dima Kogan from comment #3) > Hi. Thanks for replying. I don't the warning that I'm claiming is bogus is > complaining about the points you raised. If it did, then making g() static > or building without -fPIC or -O3 wouldn't make the warning go away. It's likely optimized away before warning. > I have some questions about your analysis, if that's ok. g() doesn't know > where its ab argument came from, so how can the strict aliasing rules be > violated? strict aliasing rules are violated because of the actual accesses, not because what a compiler or the function can or cannot see. > The only reason the compiler knows anything at all here is that > with -O3 it's tracing the flow. With -O0, there's no warning. And g() may as > well be in an entirely different compilation unit, in which case it'd > compile that unit with no complaint at any optimization level. But it's still a strict aliasing violation. > Similarly, for the undefined behavior. If I have a function that takes some > double* x, then is it undefined behavior to refer to x[-1]? If not, then how > is this different? It is undefined to refer to x[-1] in case x points to the first element of an array. This is simply how the C abstract machine defines things. "hiding" violations doesn't make them go away, you just might be more lucky in the compiler not taking advantage of the undefinedness and not "miscompiling" your code (or issueing "bogus" diagnostics).
