This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/70884] New: [6 regression] 2nd SRA pass confused by load from constant pool
- From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 29 Apr 2016 19:21:08 +0000
- Subject: [Bug tree-optimization/70884] New: [6 regression] 2nd SRA pass confused by load from constant pool
- Auto-submitted: auto-generated
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.