https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954
--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Dan Bonachea from comment #5) > (In reply to Martin Liška from comment #4) > > > Assuming it's the latter, can anyone suggest any non-intrusive > > > workarounds? > > > (aside from the obvious "big hammers" of -fno-lto or -fno-strict-aliasing) > > > > Yes, the warning should not produce bogus warnings. Proper solution is not > > to break strict aliasing. Note that it can help optimization to make more > > aggressive optimizations. > > I'm confused - are you saying the test program actually breaks C's strict > aliasing rules? My understanding was this is a correct (spec-compliant) C > program that is being mishandled by gcc. My question was whether this > mishandling could generally result in actual incorrect optimization of > programs encountering this defect, and it sounds like you are saying it > might? Yes, it's a valid C program. And yes, it's mishandled by GCC. I believe considering these two types as having different alias sets can result in an incorrect optimization.