https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94313
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 25 Mar 2020, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94313 > > --- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> --- > Removing invalid code not isn't wrong (as in non-conforming), but it's > decidedly unhelpful in avoiding the undefined behavior that doesn't > necessarily > go away just because the invalid statement is gone. It makes finding the > underlying bugs difficult. My solution for pr90404 detects most of these bugs > (and can also eliminate the buggy code) except those that are removed by DSE. > The intent of this report isn't so much to complain that GCC is doing > something > wrong but to document the rationale for doing something different (i.e., > diagnose these bugs consistently and leave it up to the user whether to > eliminate the code or replace it with a trap or something else). Usually the whole point of undefined behavior is that you do not need to detect it. When you detect undefined behavior you can try to do something sensible (try to second guess DWIM) like for example how we allow invalid type-punning when we see a trivial must-alias. In this case points-to analysis does not bother to invent something to represent not useful information because it's not useful and just wastes resources.
