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.
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$
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.
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.)
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.
(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.
> 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.
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).
> 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.
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.
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
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
Reopen if not.
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
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
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.
> 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.
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
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