> 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. >> >> [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
