Iain Sandoe <idsan...@googlemail.com> writes: >> On 22 May 2019, at 16:19, Jeff Law <l...@redhat.com> wrote: >> >> On 5/22/19 8:44 AM, Vladislav Ivanishin wrote: >>> Christophe, Rainer, >>> >>> Rainer Orth <r...@cebitec.uni-bielefeld.de> writes: >>> >>>> Hi Christophe, >>>> >>>>> On Fri, 17 May 2019 at 10:12, Vladislav Ivanishin <v...@ispras.ru> wrote: >>>>>> >>>>> As you have probably noticed already, the new test uninit-28.c fails: >>>>> /gcc/testsuite/gcc.dg/uninit-28-gimple.c:9:16: warning: 'undef' may be >>>>> used uninitialized in this function [-Wmaybe-uninitialized] >>>>> FAIL: gcc.dg/uninit-28-gimple.c (test for bogus messages, line 9) >>>>> at least on arm & aarch64 >>> >>> Thanks for spotting. I managed to reproduce the failure on x86_64 (I >>> started from revision and configure options in one of H.J.'s test >>> results [1]) and it seems, another check-in is to blame. The stage1 >>> compiler is always fine w.r.t. the result on uninit-28-gimple.c. The >>> stage2 compiler seems to be miscompiled. >>> >>> r271460 is already bad, yes, but the problem starts earlier (better to >>> pick another test as an indicator, or bisect just the stage1 compiler, >>> compiling pseudo-stage2 with it from newer sources). >>> >>> I'm going to bisect the regression and report to the appropriate thread >>> unless someone beats me to it.
OK, this is the right thread after all. Failure on uninit-28-gimple.c is fixed by Martin's patch for PR90587 (checked on x84_64-pc-linux-gnu). Thank you! If the problems persist on other tests and targets, please let me know. I'll check gcc-testresults when testers pick up the fix. Vlad >>> >>> [1]: https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg02436.html >>> >>>> I'm seeing it on sparc-sun-solaris2.11, and there are gcc-testresults >>>> reports for i?86, mips64el, powerpc*, s390x, and x86_64. >> FWIW I'm also seeing uninit-18 failing on the ppc targets. > > uninit-18, 19 are failing on x86_64-darwin16 (m32 and m64) at least, too > (although uninit-28 is passing there). > > Iain > >> >> And I'll reiterate my concern that these are likely masking issues >> earlier in the optimizer pipeline. For example uninit-18 really should >> be fixed by threading in either DOM or VRP. >> >> Jeff
