[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #3 from davem at gcc dot gnu dot org 2010-03-23 20:40 --- Sorry, it's taking a long time to sort out the test case. The GLIBC regex code is huge and non-trivial. However I did track down that it might be dependent upon optimization options, for example I can reproduce with -mtune=niagara2 but I can't reproduce without it. I'll keep working on trying to cook up a test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug c/43385] New: glibc regex testsuite failures
posix/bug-regex11 and posix/bug-regex20 in the glibc testsuite fail with gcc-4.5.0 on the trunk. gcc-4.4.x and gcc-4.3.x do not have this failure. I'll try to put together a small minimal test case and also see if i386 has the same problem to help diagnose this. -- Summary: glibc regex testsuite failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davem at gcc dot gnu dot org GCC build triplet: sparc-linux-gnu GCC host triplet: sparc-linux-gnu GCC target triplet: sparc-linux-gun http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug middle-end/34668] [4.3 Regression] ICE in find_compatible_field with -combine
--- Comment #13 from davem at gcc dot gnu dot org 2010-03-12 20:58 --- I'm still seeing this fail on 32-bit sparc with mainline: home/davem/src/GIT/GCC/gcc/gcc/testsuite/gcc.dg/pr34668-2.c: In function 'set_conv_libfunc': /home/davem/src/GIT/GCC/gcc/gcc/testsuite/gcc.dg/pr34668-2.c:5:15: error: type mismatch in array reference struct optab struct optab # .MEM_3 = VDEF .MEM_1(D) optab_table[0].code = 57005; /home/davem/src/GIT/GCC/gcc/gcc/testsuite/gcc.dg/pr34668-2.c:5:15: internal compiler error: verify_stmts failed -- davem at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34668
[Bug tree-optimization/38819] [4.3 Regression] trapping expression wrongly hoisted out of loop
--- Comment #19 from davem at gcc dot gnu dot org 2010-03-12 21:00 --- Like Eric I'm still seeing this fail on mainline on 32-bit sparc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819
[Bug target/43004] sparc 64-bit stack slot allocation overlaps with alloca
--- Comment #1 from davem at gcc dot gnu dot org 2010-02-09 22:08 --- Ok, I now know a lot more about this bug. It's effects were masked before gcc-4.4 because we used to have the TFmode secondary reload slot in every stack frame. That got removed by my commit: 2009-01-04 David S. Miller da...@davemloft.net * config/sparc/sparc.h (SECONDARY_MEMORY_NEEDED_RTX): Delete. (STARTING_FRAME_OFFSET): Always set to zero. The problem case is where the stack frame (with bias added) is only 8-byte aligned. The allocate_dynamic_stack_space() code ends up emitting (after optimizations clean it up) something like: 0x1010b00 _dl_fini+864: add %i5, 0xf, %g4 0x1010b04 _dl_fini+868: and %g4, -16, %g4 0x1010b08 _dl_fini+872: sub %sp, %g4, %sp 0x1010b0c _dl_fini+876: add %sp, 0x8be, %i2 0x1010b10 _dl_fini+880: b %xcc, 0x10108bc _dl_fini+284 0x1010b14 _dl_fini+884: and %i2, -16, %i2 %i5 is the desired alloca length, and %i2 is the final alloca() buffer pointer. Consider a start condition such as: %sp: 0x7fee399 + 2047 (BIAS) == 0x7feeb98 %i5: 0x20 We'll end up with a final %i2 value: alloca area calculation: $i2 = (%sp + 0x8be) (0x8b3 == 2047 + 176 + 15) 0x7feec37 $i2 = -16 0x7feec30 And this 0x7feec30 which is %sp + BIAS + 0xb8, or 184 decimal into the stack frame. We're supposed to use stack_frame + 176 decimal. But because of the way we've had to 16-byte align the final pointer, we're now overflowing into the local variable stack slots. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43004
[Bug target/43004] sparc 64-bit stack slot allocation overlaps with alloca
--- Comment #2 from davem at gcc dot gnu dot org 2010-02-09 22:13 --- Reading further, the Sparc 64-bit ABI requires that the every stack frame be 16 byte aligned. And if that were the case this problem would never happen. Will try to determine how the stack is becomming only 8-byte aligned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43004
[Bug target/43004] sparc 64-bit stack slot allocation overlaps with alloca
--- Comment #3 from davem at gcc dot gnu dot org 2010-02-10 00:49 --- I've root caused this to the Linux kernel not 16-byte aligning thread stacks when using the clone() system call (it was enforcing only 8-byte alignment), and also signal stacks. The seconday mem TFmode stack slot was hiding this bug. All of this does point out, however, that GCC does a lot of unnecessary alignment of the final alloca() buffer pointer. Perhaps tweaking of the MUST_ALIGN code in explow.c can fix this. -- davem at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43004
[Bug target/43004] New: sparc 64-bit stack slot allocation overlaps with alloca
When generating 64-bit code, stack slots allocated to local variables can overlap alloca areas. This bug may be specific to PIC code generation since the test case I have (elf/dl-fini.c in GLIBC) is built with -fPIC. I'm still trying to distill a small test case and, whether I can or not, I'll attach some reproducer to this bug report. -- Summary: sparc 64-bit stack slot allocation overlaps with alloca Product: gcc Version: 4.4.4 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davem at gcc dot gnu dot org GCC build triplet: sparc-unknown-linux-gnu GCC host triplet: sparc-unknown-linux-gnu GCC target triplet: sparc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43004
[Bug bootstrap/21162] Build failure
--- Additional Comments From davem at gcc dot gnu dot org 2005-04-22 18:08 --- Yes, it should just work. And it would have if you: 1) Make sure /lib64/libc.so.6 is installed. 2) Delete the file /etc/disable_64_gcc Then gcc would output 64-bit code by default when the uname command outputs sparc64. You could then simply run sparc32 bash to get an environment where uname outputs plain sparc and this causes the Debian gcc to output 32-bit code by default. We plan on adding similar logic to the compiler driver itself. I totally agree with you that when uname outputs sparc64 the compiler on the system should be outputting 64-bit code by default which is what many (not just gcc's) configure scripts and build trees expect. Since this problem has to do with Debian's gcc behavior and not with a gcc proper bug per-se, I'm closing this as invalid. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug bootstrap/21162] Build failure
--- Additional Comments From davem at gcc dot gnu dot org 2005-04-22 18:21 --- Right, it can't compile a test program with -m64 because the /lib64/libc.so.6 package is not installed. Also, when you use sparc32 you should use it to create a complete execution environment with sparc32 bash or whatever shell you use. You need to be in that environment when you invoke the make, not just when you run the configure scripts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug bootstrap/21162] Build failure
--- Additional Comments From davem at gcc dot gnu dot org 2005-04-22 18:27 --- You may with to restart your build with the correct environment setup, just to be safe. Depending upon what you've enabled it can take a long time :-) Yes, the /etc/disable_64_gcc file is what prevents gcc from outputting 64-bit code by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21162
[Bug target/20673] [4.0 only] C PCH testsuite assembly comparison failure
--- Additional Comments From davem at gcc dot gnu dot org 2005-04-15 19:26 --- This should be fixed both in mainline and the 4.0 branch -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20673
