[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #13 from Jeffrey A. Law --- I wouldn't lose any sleep if init-regs.c disappeared. The comment about the ARM ISA being unable to encode certain cases isn't a strong case in my mind to do something like init-regs.c. We've dealt with similar problems in other ports -- you just have to get creative in other ways. I can recall dealing with ports that couldn't encode a nop-move for example.
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-02 CC||law at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Component|middle-end |rtl-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- This is probably caused by init-regs.c which is done conditionally on optimize > 0 only. IMHO it should be removed (this was discussed repeatedly in the past).
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 Eric Botcazou changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Eric Botcazou --- 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.
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 Richard Biener changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Richard Biener --- I remember bootstrapping and testing with the pass removed just works.
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #4 from rguenther at suse dot de --- On Wed, 2 Dec 2015, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 > > Eric Botcazou changed: > >What|Removed |Added > >Severity|normal |enhancement > > --- Comment #3 from Eric Botcazou --- > 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. True, just that we avoid uninitialized regs at -O1+ but not on -O0 makes this one valid. OTOH I'd just use it as an excuse to drop init-regs.c ...
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #6 from Eric Botcazou --- > OTOH I'd just use it as an excuse to drop init-regs.c ... It has a rather big comment explaining why it was needed though.
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #7 from rguenther at suse dot de --- On Wed, 2 Dec 2015, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 > > --- Comment #6 from Eric Botcazou --- > > OTOH I'd just use it as an excuse to drop init-regs.c ... > > It has a rather big comment explaining why it was needed though. Handwaving ones w/o testcase and appearantly without making sure such uses never get re-introduced after it (and the offending un-named places)
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #10 from Joost VandeVondele --- (In reply to rguent...@suse.de from comment #9) > Though with the testcase you gave we warn at both -O0 and -O1: yes, but unfortunately, -Wuninitialized, also warns for 'may be used uninitialized' which are too often false positives, and sometimes even compiler generated variables as in PR67679. A -Wmust-be-uninitialized (which seemingly the compiler could do as the comment on top of init-regs.c suggests) would be valuable. [I just checked that -Wuninitialized -Wno-maybe-uninitialized doesn't work]
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #5 from Richard Biener --- See PR61810 which shows missed optimizations because of init-regs.c
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #8 from Joost VandeVondele --- (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.
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #11 from Marc Glisse --- (In reply to Joost VandeVondele from comment #10) > [I just checked that -Wuninitialized -Wno-maybe-uninitialized doesn't work] That sounds like a bug. It works for me on a simple C testcase.
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #9 from 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 changed: > >What|Removed |Added > > CC||Joost.VandeVondele at mat > dot ethz >||.ch > > --- Comment #8 from Joost VandeVondele 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]
[Bug rtl-optimization/68641] undefined variables implicitly considered to be zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641 --- Comment #12 from Joost VandeVondele --- (In reply to Marc Glisse from comment #11) > That sounds like a bug. It works for me on a simple C testcase. sorry, fat fingers on my side. So, yes, this works gfortran -c -Werror=uninitialized -Wno-maybe-uninitialized test.f90 I believe this would practically resolve this PR from my point of view.
