On 01/27/2016 05:14 PM, David Edelsohn wrote:
On Wed, Jan 27, 2016 at 6:36 PM, Jeff Law wrote:
On 01/27/2016 12:39 PM, David Edelsohn wrote:
The new sra-17.c and sra-18.c tests fail on AIX because the regex is
too restrictive -- AIX labels don't have exactly the same format.
On 01/27/2016 12:39 PM, David Edelsohn wrote:
The new sra-17.c and sra-18.c tests fail on AIX because the regex is
too restrictive -- AIX labels don't have exactly the same format. On
AIX, the labels in the dumps look like "LC..0" instead of ".LC0".
This patch adds "*" and ".*" so that the "."
On Wed, Jan 27, 2016 at 6:36 PM, Jeff Law wrote:
> On 01/27/2016 12:39 PM, David Edelsohn wrote:
>>
>> The new sra-17.c and sra-18.c tests fail on AIX because the regex is
>> too restrictive -- AIX labels don't have exactly the same format. On
>> AIX, the labels in the dumps
The new sra-17.c and sra-18.c tests fail on AIX because the regex is
too restrictive -- AIX labels don't have exactly the same format. On
AIX, the labels in the dumps look like "LC..0" instead of ".LC0".
This patch adds "*" and ".*" so that the "." prepended to LC is
optional and to allow
On Fri, Jan 15, 2016 at 11:27 AM, Alan Lawrence
wrote:
> On 24/12/15 11:53, Alan Lawrence wrote:
>>
>> Here's a new version that fixes the gcc.dg/guality/pr54970.c failures seen
>> on
>> aarch64 and powerpc64. Prior to SRA handling constant pool decls,
>>
On 24/12/15 11:53, Alan Lawrence wrote:
Here's a new version that fixes the gcc.dg/guality/pr54970.c failures seen on
aarch64 and powerpc64. Prior to SRA handling constant pool decls,
-fdump-tree-esra-details (at -O1 -g) had shown:
:
a = *.LC0;
# DEBUG a$0 => MEM[(int[3] *)&*.LC0]
On 24/12/15 11:53, Alan Lawrence wrote:
Here's a new version that fixes the gcc.dg/guality/pr54970.c failures seen on
aarch64 and powerpc64.
[snip]
This also fixes a bunch of other guality tests on AArch64 that were failing
prior to the patch series, and another bunch on PowerPC64 (bigendian
Here's a new version that fixes the gcc.dg/guality/pr54970.c failures seen on
aarch64 and powerpc64. Prior to SRA handling constant pool decls,
-fdump-tree-esra-details (at -O1 -g) had shown:
:
a = *.LC0;
# DEBUG a$0 => MEM[(int[3] *)&*.LC0]
a$4_3 = MEM[(int[3] *)&*.LC0 + 4B];
# DEBUG
This is the same as the version conditionally approved near the end of stage 1
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01948.html, plus the
requested comment and a couple of testcases for platforms where the constants
are pushed into the constant pool. (I didn't commit this at the time