This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/70884] New: [6 regression] 2nd SRA pass confused by load from constant pool


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70884

            Bug ID: 70884
           Summary: [6 regression] 2nd SRA pass confused by load from
                    constant pool
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
            Target: powerpc-linux

Created attachment 38382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38382&action=edit
Testcase

It's a regression introduced by the enhancement to SRA aimed at scalarizing
loads from the constant pool: when the 2nd pass is run on the results of the
1st pass, things can go astray.

Testcase attached and to compiled with -O -fno-tree-fre, but unfortunately it
requires a specific tuning setup that is only present on PowerPC 32-bit:

Target: powerpc-generic-linux-gnu
Configured with: ../src/configure --enable-languages=ada,c,c++
--enable-dual-exceptions --enable-_cxa_atexit --enable-threads=posix
--with-bugurl=URL:mailto:report@adacore.com --disable-nls
--without-libiconv-prefix --disable-libstdcxx-pch --disable-libada
--enable-checking=release
--with-mpfr=/mystic.a/gnatmail/sandbox/gcc-6/ppc-linux/mpfr_stable/install
--with-gmp=/mystic.a/gnatmail/sandbox/gcc-6/ppc-linux/gmp_stable/install
--with-mpc=/mystic.a/gnatmail/sandbox/gcc-6/ppc-linux/mpc_stable/install
--with-build-time-tools=/mystic.a/gnatmail/sandbox/gcc-6/ppc-linux/gcc/build/buildtools/bin
--prefix=/mystic.a/gnatmail/sandbox/gcc-6/ppc-linux/gcc/pkg
--build=powerpc-generic-linux-gnu

(botcazou@mystic) ~ $ gcc -o t t.c -O -fno-tree-fre
(botcazou@mystic) ~ $ ./t
Aborted

But the problem is clearly visible in the tree dumps with a cross-compiler.

In .108t.cplxlower1:

 <bb 2>:
  SR.0_6 = *.LC0.a;
  MEM[(struct S *)&s1] = SR.0_6;
  MEM[(struct S *)&s1 + 4B] = 1;
  foo (s1);
  s1 ={v} {CLOBBER};
  SR.2_4 = *.LC0.a;
  MEM[(struct S *)&s2] = SR.2_4;
  MEM[(struct S *)&s2 + 4B] = 1;
  foo (s2);
  s2 ={v} {CLOBBER};

In .109t.sra:

  <bb 2>:
  SR.0_6 = SR.4_7(D);
  MEM[(struct S *)&s1] = SR.0_6;
  MEM[(struct S *)&s1 + 4B] = 1;
  foo (s1);
  s1 ={v} {CLOBBER};
  SR.2_4 = SR.4_7(D);
  MEM[(struct S *)&s2] = SR.2_4;
  MEM[(struct S *)&s2 + 4B] = 1;
  foo (s2);
  s2 ={v} {CLOBBER};

Note the bogus new (D) thing created by SRA.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]