https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 2 Dec 2015, Joost.VandeVondele at mat dot ethz.ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 > > Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |Joost.VandeVondele at mat > dot ethz > | |.ch > > --- Comment #8 from Joost VandeVondele <Joost.VandeVondele at mat dot > ethz.ch> --- > (In reply to Eric Botcazou from comment #3) > > The whole reasoning looks fairly dubious to me, the optimizer is free to do > > whatever it wants on undefined behavior and requests that the generated code > > behaves identically at all optimization levels on it have little merit IMO. > > Of course, I agree that the code has undefined behavior, and that 'all bets > are > off'. > > It just makes it more difficult for users to spot this undefined > behavior, we run our testsuite every night under valgrind, but can't > move from -O1 to -O0, since that would add a couple of hours to the > test. Admittedly, -fsanitize=memory would be a better solution, but it > is not available with gcc. Though with the testcase you gave we warn at both -O0 and -O1: > gfortran-5 t.f90 -c -Wall -O t.f90:3:0: IF (i/=0) CALL link_error ^ Warning: ‘i’ is used uninitialized in this function [-Wuninitialized] t.f90:4:0: IF (ASSOCIATED(foo)) CALL link_error ^ Warning: ‘foo’ is used uninitialized in this function [-Wuninitialized]
