Bug 51315 - [4.6/4.7 regression] unaligned memory accesses generated with -ftree-sra
Summary: [4.6/4.7 regression] unaligned memory accesses generated with -ftree-sra
Status: VERIFIED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.6.2
: P3 normal
Target Milestone: 4.6.3
Assignee: Eric Botcazou
URL: http://gcc.gnu.org/ml/gcc-patches/201...
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2011-11-26 16:54 UTC by Jurij Smakov
Modified: 2012-01-05 22:24 UTC (History)
3 users (show)

See Also:
Host:
Target: sparc*-*-*
Build:
Known to work: 4.4.6, 4.5.4
Known to fail: 4.6.2, 4.7.0
Last reconfirmed: 2011-12-04 00:00:00


Attachments
Preprocessed test case code (5.55 KB, application/octet-stream)
2011-11-26 16:54 UTC, Jurij Smakov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jurij Smakov 2011-11-26 16:54:09 UTC
Created attachment 25914 [details]
Preprocessed test case code

Hello,

There appears to be a bug in gcc (reproducible with gcc 4.6.2 currently in Debian unstable), noticed due to Ruby 1.9.x build failures on sparc. The code gets miscompiled resulting either in bogus results or bus error with -O2, however the problem goes away when building with -O2 -fno-tree-sra, so tree optimization is highly suspect. Attached please find a simple standalone case in preprocessed form, instructions on how to reproduce are included below.

Compiling with -O2, generates broken code:

jurij@debian:~/ftree-sra$ gcc -v -save-temps -g -O2 pack.c -o pack
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc-linux-gnu/4.6/lto-wrapper
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --with-long-double-128 --enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu
Thread model: posix
gcc version 4.6.2 (Debian 4.6.2-5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-O2' '-o' 'pack' '-mcpu=ultrasparc'
 /usr/lib/gcc/sparc-linux-gnu/4.6/cc1 -E -quiet -v -imultilib . -imultiarch sparc-linux-gnu -D__sparc_v9__ pack.c -mcpu=ultrasparc -g -fworking-directory -O2 -fpch-preprocess -o pack.i
ignoring nonexistent directory "/usr/local/include/sparc-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/sparc-linux-gnu/4.6/../../../../sparc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/sparc-linux-gnu/4.6/include
 /usr/local/include
 /usr/lib/gcc/sparc-linux-gnu/4.6/include-fixed
 /usr/include/sparc-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-O2' '-o' 'pack' '-mcpu=ultrasparc'
 /usr/lib/gcc/sparc-linux-gnu/4.6/cc1 -fpreprocessed pack.i -quiet -dumpbase pack.c -mcpu=ultrasparc -auxbase pack -g -O2 -version -o pack.s
GNU C (Debian 4.6.2-5) version 4.6.2 (sparc-linux-gnu)
	compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (Debian 4.6.2-5) version 4.6.2 (sparc-linux-gnu)
	compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 25439f394be45745a7ad849d22cd1d06
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-O2' '-o' 'pack' '-mcpu=ultrasparc'
 as -s -Av9a -32 -relax -o pack.o pack.s
COMPILER_PATH=/usr/lib/gcc/sparc-linux-gnu/4.6/:/usr/lib/gcc/sparc-linux-gnu/4.6/:/usr/lib/gcc/sparc-linux-gnu/:/usr/lib/gcc/sparc-linux-gnu/4.6/:/usr/lib/gcc/sparc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/sparc-linux-gnu/4.6/:/usr/lib/gcc/sparc-linux-gnu/4.6/../../../sparc-linux-gnu/:/usr/lib/gcc/sparc-linux-gnu/4.6/../../../../lib/:/lib/sparc-linux-gnu/:/lib/../lib/:/usr/lib/sparc-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/sparc-linux-gnu/4.6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-O2' '-o' 'pack' '-mcpu=ultrasparc'
 /usr/lib/gcc/sparc-linux-gnu/4.6/collect2 --build-id --no-add-needed --eh-frame-hdr -m elf32_sparc -Y P,/usr/lib -dynamic-linker /lib/ld-linux.so.2 -relax -o pack /usr/lib/gcc/sparc-linux-gnu/4.6/../../../sparc-linux-gnu/crt1.o /usr/lib/gcc/sparc-linux-gnu/4.6/../../../sparc-linux-gnu/crti.o /usr/lib/gcc/sparc-linux-gnu/4.6/crtbegin.o -L/usr/lib/gcc/sparc-linux-gnu/4.6 -L/usr/lib/gcc/sparc-linux-gnu/4.6/../../../sparc-linux-gnu -L/usr/lib/gcc/sparc-linux-gnu/4.6/../../../../lib -L/lib/sparc-linux-gnu -L/lib/../lib -L/usr/lib/sparc-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/sparc-linux-gnu/4.6/../../.. pack.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/sparc-linux-gnu/4.6/crtend.o /usr/lib/gcc/sparc-linux-gnu/4.6/../../../sparc-linux-gnu/crtn.o
jurij@debian:~/ftree-sra$ 

Resulting binary crashes with a 'bus error':

jurij@debian:~/ftree-sra$ gdb pack
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/jurij/ftree-sra/pack...done.
(gdb) run
Starting program: /home/jurij/ftree-sra/pack 
do_something called with item=-32767

Program received signal SIGBUS, Bus error.
pack_unpack (s=0x1068a "\377\376\035\300", p=0x10692 "") at pack.c:62
62			memcpy (v.a, s, sizeof (int32_t));
(gdb) disass
Dump of assembler code for function pack_unpack:
   0x000104a0 <+0>:	save  %sp, -96, %sp
   0x000104a4 <+4>:	call  0x207d0 <strlen@plt>
   0x000104a8 <+8>:	mov  %i1, %o0
   0x000104ac <+12>:	add  %i1, %o0, %i5
   0x000104b0 <+16>:	cmp  %i1, %i5
   0x000104b4 <+20>:	bcs,a   %icc, 0x104e0 <pack_unpack+64>
   0x000104b8 <+24>:	ldub  [ %i1 ], %g1
   0x000104bc <+28>:	rett  %i7 + 8
   0x000104c0 <+32>:	ldsb  [ %o0 ], %o0
   0x000104c4 <+36>:	cmp  %g1, 0x73
   0x000104c8 <+40>:	be,a,pn   %icc, 0x10518 <pack_unpack+120>
   0x000104cc <+44>:	lduh  [ %i0 ], %o0
   0x000104d0 <+48>:	cmp  %i1, %i5
   0x000104d4 <+52>:	be,a,pn   %icc, 0x10510 <pack_unpack+112>
   0x000104d8 <+56>:	ldsb  [ %i0 ], %i0
   0x000104dc <+60>:	ldub  [ %i1 ], %g1
   0x000104e0 <+64>:	sll  %g1, 0x18, %g1
   0x000104e4 <+68>:	sra  %g1, 0x18, %g1
   0x000104e8 <+72>:	cmp  %g1, 0x6c
   0x000104ec <+76>:	bne  %icc, 0x104c4 <pack_unpack+36>
   0x000104f0 <+80>:	inc  %i1
=> 0x000104f4 <+84>:	ld  [ %i0 ], %o0
   0x000104f8 <+88>:	call  0x10480 <do_something>
   0x000104fc <+92>:	add  %i0, 4, %i0
   0x00010500 <+96>:	cmp  %i1, %i5
   0x00010504 <+100>:	bne,a   %icc, 0x104e0 <pack_unpack+64>
   0x00010508 <+104>:	ldub  [ %i1 ], %g1
   0x0001050c <+108>:	ldsb  [ %i0 ], %i0
   0x00010510 <+112>:	rett  %i7 + 8
   0x00010514 <+116>:	nop 
   0x00010518 <+120>:	add  %i0, 2, %i0
   0x0001051c <+124>:	sll  %o0, 0x10, %o0
   0x00010520 <+128>:	call  0x10480 <do_something>
   0x00010524 <+132>:	sra  %o0, 0x10, %o0
   0x00010528 <+136>:	b  %xcc, 0x104d4 <pack_unpack+52>
   0x0001052c <+140>:	cmp  %i1, %i5
End of assembler dump.
(gdb) info reg i0
i0             0x1068a	67210
(gdb) 

Building with -fno-tree-sra fixes the problem:

jurij@debian:~/ftree-sra$ gcc -g -O2 -fno-tree-sra pack.c -o pack
jurij@debian:~/ftree-sra$ ./pack 
do_something called with item=-32767
do_something called with item=-123456
jurij@debian:~/ftree-sra$ 

This bug is tracked in Debian as http://bugs.debian.org/635126. Please let me know if you would like any other information.

Thanks.
Comment 1 Jurij Smakov 2011-11-28 23:45:19 UTC
Debian gcc maintainers suggested that I try to build the test case with various gcc versions available in Debian and post the results here. Here's a summary:

Debian's gcc-4.4 is not affected:

jurij@debian:~/ftree-sra$ gcc-4.4 -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.6-11' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-long-double-128 --enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu
Thread model: posix
gcc version 4.4.6 (Debian 4.4.6-11) 
jurij@debian:~/ftree-sra$ 
jurij@debian:~/ftree-sra$ gcc-4.4 -g -O2 -ftree-sra pack.c -o pack
jurij@debian:~/ftree-sra$ ./pack 
do_something called with item=-32767
do_something called with item=-123456
jurij@debian:~/ftree-sra$

Debian's gcc-4.5 is not affected:

jurij@debian:~/ftree-sra$ gcc-4.5 -v
Using built-in specs.
COLLECT_GCC=gcc-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc-linux-gnu/4.5.3/lto-wrapper
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.3-9' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --enable-targets=all --with-long-double-128 --enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu
Thread model: posix
gcc version 4.5.3 (Debian 4.5.3-9) 
jurij@debian:~/ftree-sra$ 
jurij@debian:~/ftree-sra$ gcc-4.5 -g -O2 -ftree-sra pack.c -o pack
jurij@debian:~/ftree-sra$ ./pack 
do_something called with item=-32767
do_something called with item=-123456
jurij@debian:~/ftree-sra$ 

Debian's gcc-snapshot is affected:

jurij@debian:~/ftree-sra$ export PATH=/usr/lib/gcc-snapshot/bin:${PATH}
jurij@debian:~/ftree-sra$ which gcc
/usr/lib/gcc-snapshot/bin/gcc
jurij@debian:~/ftree-sra$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/sparc-linux-gnu/4.7.0/lto-wrapper
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20111103-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --with-system-zlib --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.7-snap/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.7-snap --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.7-snap --with-arch-directory=sparc --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --with-long-double-128 --disable-werror --enable-checking=yes --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu
Thread model: posix
gcc version 4.7.0 20111103 (experimental) [trunk revision 180824] (Debian 20111103-1) 
jurij@debian:~/ftree-sra$ gcc -g -O2 -ftree-sra pack.c -o pack
jurij@debian:~/ftree-sra$ ./pack 
do_something called with item=-32767
Bus error
jurij@debian:~/ftree-sra$ gcc -g -O2 -fno-tree-sra pack.c -o pack
jurij@debian:~/ftree-sra$ ./pack 
do_something called with item=-32767
do_something called with item=-123456
jurij@debian:~/ftree-sra$
Comment 2 Mikael Pettersson 2011-11-29 09:54:05 UTC
The SIGBUS is due to a misaligned address at the machine code level.

On sparc64-linux -m32 I can reproduce the SIGBUS with current 4.7 and 4.6, but not with 4.5 or 4.4.  On armv5tel-linux-gnueabi the test case causes an alignment exception (logged and fixed up by the kernel) when compiled by 4.7 or 4.6, but not when compiled by 4.5 or 4.4.

I believe this is a dupe of one of the other alignments bugs in 4.6+ affecting at least sparc and arm.
Comment 3 Mikael Pettersson 2011-11-29 10:18:00 UTC
I suspect it's a dupe of PR50569 or PR50444.

(And if you hate alignment bugs like me you might also want to know about the 4.5-only PR46483.)
Comment 4 Jurij Smakov 2011-12-01 09:26:54 UTC
So, how do we convince someone to fix it? As Mikael points out, the same or very similar problem has already been reported multiple times, and it appears that other PRs have the offending commits identified.

This does cause problems for Debian, as we are adopting gcc-4.6 for the next release, and if this bug remains unfixed, we will have to do something ugly, like use -fno-tree-sra by default at least on sparc.
Comment 5 Mikael Pettersson 2011-12-03 18:35:26 UTC
(In reply to comment #3)
> I suspect it's a dupe of PR50569 or PR50444.

It's not, this one is caused by r161655 (Richard G's big MEM-REF change):
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00006.html

Comparing the code from r161654 and r161655, targeting sparc-linux, we see:

--- pr51315.s-r161654   2011-12-03 18:58:02.000000000 +0100
+++ pr51315.s-r161655   2011-12-03 19:12:41.000000000 +0100
@@ -22,7 +22,7 @@
        .type   pack_unpack, #function
        .proc   04
 pack_unpack:
-       save    %sp, -104, %sp
+       save    %sp, -96, %sp
        call    strlen, 0
         mov    %i1, %o0
        add     %i1, %o0, %i5
@@ -35,7 +35,7 @@
 .LL12:
        cmp     %g1, 115
        be,a    .LL11
-        ldub   [%i0], %g2
+        lduh   [%i0], %o0
        cmp     %i5, %i1
 .LL14:
        bleu,a  .LL13
@@ -48,16 +48,8 @@
        cmp     %g1, 108
        bne     .LL12
         add    %i1, 1, %i1
-       ldub    [%i0], %g4
-       ldub    [%i0+1], %g3
-       ldub    [%i0+2], %g2
-       ldub    [%i0+3], %g1
-       stb     %g4, [%fp-8]
-       stb     %g3, [%fp-7]
-       stb     %g2, [%fp-6]
-       stb     %g1, [%fp-5]
        call    do_something, 0
-        ld     [%fp-8], %o0
+        ld     [%i0], %o0
        cmp     %i5, %i1
        bgu     .LL8
         add    %i0, 4, %i0
@@ -67,12 +59,10 @@
         restore
 .LL11:
 .LL6:
-       ldub    [%i0+1], %g1
-       stb     %g2, [%fp-2]
-       stb     %g1, [%fp-1]
        add     %i0, 2, %i0
+       sll     %o0, 16, %o0
        call    do_something, 0
-        ldsh   [%fp-2], %o0
+        sra    %o0, 16, %o0
        b       .LL14
         cmp    %i5, %i1
        .size   pack_unpack, .-pack_unpack

> (And if you hate alignment bugs like me you might also want to know about the
> 4.5-only PR46483.)

Minor correction: PR46483 also affects gcc-4.4.
Comment 6 Eric Botcazou 2011-12-04 18:20:36 UTC
> It's not, this one is caused by r161655 (Richard G's big MEM-REF change):
> http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00006.html

Investigating then.
Comment 7 Richard Biener 2011-12-06 14:16:21 UTC
Note that in the end it's always us transforming

 a->b.c

to (effectively)

 T *tem = &a->b.c;
 *tem

which expand unfortunately handles differently.  So whenever we do that
we have to either avoid doing that if expand would have a different
idea about the results alignment (there is currently no way that computes
just expands idea of an expressions alignment - one piece of a good
solution would provide that, not only SRA has this "issue"), or, stick
that information somewhere (on the TREE_TYPE of the MEM_REF tree, but
then it will only be honoured if the target provides a movmisalign
optab - the other piece of a good solution would be that expand _always_
honors such alignment information and goes the same way as when expanding
component refs).
Comment 8 Eric Botcazou 2011-12-06 16:41:38 UTC
> Note that in the end it's always us transforming
> 
>  a->b.c
> 
> to (effectively)
> 
>  T *tem = &a->b.c;
>  *tem
> 
> which expand unfortunately handles differently.  So whenever we do that
> we have to either avoid doing that if expand would have a different
> idea about the results alignment (there is currently no way that computes
> just expands idea of an expressions alignment - one piece of a good
> solution would provide that, not only SRA has this "issue"), or, stick
> that information somewhere

AFAICS that's what the memcpy folder does if STRICT_ALIGNMENT, so the generated GIMPLE is perfectly valid.   But SRA isn't as cautious as the folder and, in particular, doesn't compare the alignments of source and destination.  In any case, I don't think that we want to patch outside SRA on the 4.6 branch.
Comment 9 rguenther@suse.de 2011-12-07 11:36:55 UTC
On Tue, 6 Dec 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315
> 
> --- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-12-06 16:41:38 UTC ---
> > Note that in the end it's always us transforming
> > 
> >  a->b.c
> > 
> > to (effectively)
> > 
> >  T *tem = &a->b.c;
> >  *tem
> > 
> > which expand unfortunately handles differently.  So whenever we do that
> > we have to either avoid doing that if expand would have a different
> > idea about the results alignment (there is currently no way that computes
> > just expands idea of an expressions alignment - one piece of a good
> > solution would provide that, not only SRA has this "issue"), or, stick
> > that information somewhere
> 
> AFAICS that's what the memcpy folder does if STRICT_ALIGNMENT, so the generated
> GIMPLE is perfectly valid.   But SRA isn't as cautious as the folder and, in
> particular, doesn't compare the alignments of source and destination.  In any
> case, I don't think that we want to patch outside SRA on the 4.6 branch.

The memcpy folder is very conservative, Martin patched SRA to that
effect for STRICT_ALIGNMENT targets but that caused a lot of SRA
regressions for those targets (and now we have a testcase involving
SSE vector moves, thus, on a non-STRICT_ALIGNMENT target).

But yes, dumbing down SRA is easy - there is a single function that
guards "possibly unaligned" accesses.

Richard.
Comment 10 Eric Botcazou 2011-12-08 09:05:42 UTC
Author: ebotcazou
Date: Thu Dec  8 09:05:38 2011
New Revision: 182102

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182102
Log:
	PR tree-optimization/51315
	* tree.h (get_object_or_type_alignment): Declare.
	* expr.c (get_object_or_type_alignment): Move to...
	* builtins.c (get_object_or_type_alignment): ...here.  Add assertion.
	* tree-sra.c (tree_non_mode_aligned_mem_p): Rename to...
	(tree_non_aligned_mem_p): ...this.  Add ALIGN parameter.  Look into
	MEM_REFs and use get_object_or_type_alignment for them.
	(build_accesses_from_assign): Adjust for above change.
	(access_precludes_ipa_sra_p): Likewise.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/20111208-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/expr.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-sra.c
    trunk/gcc/tree.h
Comment 11 Eric Botcazou 2011-12-08 09:12:15 UTC
Author: ebotcazou
Date: Thu Dec  8 09:12:12 2011
New Revision: 182103

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182103
Log:
	PR tree-optimization/51315
	* tree-sra.c (tree_non_mode_aligned_mem_p): Rename to...
	(tree_non_aligned_mem_p): ...this.  Add ALIGN parameter.  Look into
	MEM_REFs and use get_object_or_type_alignment for them.
	(build_accesses_from_assign): Adjust for above change.
	(access_precludes_ipa_sra_p): Likewise.
ada/
	Backport from mainline
	2011-09-25  Eric Botcazou  <ebotcazou@adacore.com>

	* gcc-interface/decl.c (gnat_to_gnu_entity) <object>: Do not promote
	the alignment if this doesn't prevent BLKmode access to the object.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/20111208-1.c
      - copied unchanged from r182102, trunk/gcc/testsuite/gcc.c-torture/execute/20111208-1.c
    branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/frame_overflow.ads
      - copied unchanged from r182090, trunk/gcc/testsuite/gnat.dg/frame_overflow.ads
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/ada/ChangeLog
    branches/gcc-4_6-branch/gcc/ada/gcc-interface/decl.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/frame_overflow.adb
    branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/specs/addr1.ads
    branches/gcc-4_6-branch/gcc/tree-sra.c
Comment 12 Eric Botcazou 2011-12-08 09:18:55 UTC
Reopen if not.
Comment 13 Georg-Johann Lay 2011-12-08 12:38:41 UTC
Author: gjl
Date: Thu Dec  8 12:38:35 2011
New Revision: 182109

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182109
Log:
	PR tree-optimization/51315
	* gcc.c-torture/execute/20111208-1.c: Fix wrong assumption
	sizeof(int)==4.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.c-torture/execute/20111208-1.c
Comment 14 Georg-Johann Lay 2011-12-08 13:57:51 UTC
Author: gjl
Date: Thu Dec  8 13:57:43 2011
New Revision: 182115

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182115
Log:
	* gcc.c-torture/execute/20111208-1.c (int16_t): Use __INT16_TYPE__
	for typedef.
	(int32_t): Use __INT32_TYPE__ for typedef.
	PR tree-optimization/51315


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.c-torture/execute/20111208-1.c
Comment 15 Jurij Smakov 2011-12-10 10:51:59 UTC
Eric, thanks a lot for the fix, your work is very much appreciated! The fix is already in Debian unstable and Ruby can be built again on sparc.
Comment 16 Eric Botcazou 2011-12-10 12:00:54 UTC
> Eric, thanks a lot for the fix, your work is very much appreciated! The fix is
> already in Debian unstable and Ruby can be built again on sparc.

You're welcome.  Thanks for confirming that the original problem has been fixed.
Comment 17 Eric Botcazou 2012-01-05 22:21:34 UTC
Author: ebotcazou
Date: Thu Jan  5 22:21:29 2012
New Revision: 182932

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182932
Log:
	PR tree-optimization/51315
	* tree-sra.c (tree_non_aligned_mem_for_access_p): New predicate.
	(build_accesses_from_assign): Use it instead of tree_non_aligned_mem_p.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/20120105-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-sra.c
Comment 18 Eric Botcazou 2012-01-05 22:24:55 UTC
Author: ebotcazou
Date: Thu Jan  5 22:24:45 2012
New Revision: 182933

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182933
Log:
	PR tree-optimization/51315
	* tree-sra.c (tree_non_aligned_mem_for_access_p): New predicate.
	(build_accesses_from_assign): Use it instead of tree_non_aligned_mem_p.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/20120105-1.c
      - copied unchanged from r182932, trunk/gcc/testsuite/gcc.c-torture/execute/20120105-1.c
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/tree-sra.c