[Bug c/36697] New: SIGSEGV on program exit with gcc 4.3.1
I get SIGSEGV when my C and C++ programs exits. I have tracked it down to the
__do_global_dtors_aux function. The newly added code under HIDDEN_DTOR_LIST_END
does not check if the function ptr from the list is 0 - which the old code
below does. On my platform (no-mmu ARM, uclibc, uclinux) at least there are
zero-pointers in that __DTOR_LIST__.
This patch solved the issue for me:
--- gcc-4.3.1.org/gcc/crtstuff.c2008-07-02 15:52:23.0 +0200
+++ gcc-4.3.1/gcc/crtstuff.c2008-07-02 17:03:35.0 +0200
@@ -298,6 +298,7 @@
while (dtor_idx max_idx)
{
f = __DTOR_LIST__[++dtor_idx];
+ if (!f) break;
f ();
}
}
--
Summary: SIGSEGV on program exit with gcc 4.3.1
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benny at ammitzboell-consult dot dk
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: arm-linux-uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36697
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #8 from benny at ammitzboell-consult dot dk 2008-06-19 14:07 --- Works on gcc 4.3.1 -- benny at ammitzboell-consult dot dk changed: What|Removed |Added Known to work|3.4.6 |3.4.6 4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #7 from benny at ammitzboell-consult dot dk 2008-06-16 09:10 --- test.c also fails with gcc 3.4.6 - testcpp.cpp however works with gcc 3.4.6. -- benny at ammitzboell-consult dot dk changed: What|Removed |Added Severity|normal |major Known to fail|4.2.3 4.2.4 |4.2.3 4.2.4 3.4.6 Known to work||3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] New: gcc 4.2.x generates wrong code for ARM target
We have encountered what seems to be a gcc bug in the attempt to upgrade our toolchain (using buildroot, embedded ARM no-MMU CPU) from 3.4.6 to 4.2.x. The bug has been seen on both 4.2.3 and 4.2.4. We have not yet been able to build a toolchain based on gcc 4.3.1. Most of our +5 MB system runs fine, but some strange problems we had boiled down to the attached test programs which essentially deals with passing some int parms and a struct through two function calls. The test code fails when executed on the ARM target. It works on x86 using gcc 4.2.3 and also on a MIPS platform using gcc 4.2.1. The test code only fails with -O2. Compiled using: [EMAIL PROTECTED]:~/src/kuss/tmp$ /home/bla/src/kuss/bs/toolchain/linux24/usr/bin/arm-elf-gcc -save-temps -c -Wall -Werror -O2 -g -Wa,-W -o .o/arm4/test.o test.c [EMAIL PROTECTED]:~/src/kuss/tmp$ /home/bla/src/kuss/bs/toolchain/linux24/usr/bin/arm-elf-g++ -save-temps -c -Wall -Werror -O2 -g -Wa,-W -o .o/arm4/testcpp.o testcpp.cpp Output from the C test run on target: :/ /bin/test ### C test: Values before test: 1 2 3 4 ### FAILS: 0x0001 0x0002 0x0004 0x0004 ### OK Output from the C++ test run on target: :/ /bin/testcpp ### C++ test: Values before test: 1 2 3 4 ### FAILS: 0x0001 0x0002 0x0004 0x0004 ### OK [EMAIL PROTECTED]:~/src/kuss/tmp$ ../bs/toolchain/linux24/usr/bin/arm-elf-gcc -v Using built-in specs. Target: arm-linux-uclibc Configured with: /home/bla/src/kuss/opensrc/gpl/toolchains/arm-gcc4/toolchain_build_arm/gcc-4.2.4/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c,c++ --with-sysroot=/home/bla/src/kuss/bs/toolchain/linux24 --with-build-time-tools=/home/bla/src/kuss/bs/toolchain/linux24/usr/arm-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-libgomp --disable-libmudflap --disable-shared --with-gmp=/home/bla/src/kuss/opensrc/gpl/toolchains/arm-gcc4/toolchain_build_arm/gmp --with-mpfr=/home/bla/src/kuss/opensrc/gpl/toolchains/arm-gcc4/toolchain_build_arm/mpfr --disable-nls --enable-threads --disable-multilib --with-float=soft --with-arch=armv4 --with-tune=arm7tdmi Thread model: posix gcc version 4.2.4 -- Summary: gcc 4.2.x generates wrong code for ARM target Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: benny at ammitzboell-consult dot dk GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: arm-linux-uclibc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #1 from benny at ammitzboell-consult dot dk 2008-06-13 12:59 --- Created an attachment (id=15762) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15762action=view) C test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #2 from benny at ammitzboell-consult dot dk 2008-06-13 13:00 --- Created an attachment (id=15763) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15763action=view) C++ test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #3 from benny at ammitzboell-consult dot dk 2008-06-13 13:00 --- Created an attachment (id=15764) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15764action=view) test.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #4 from benny at ammitzboell-consult dot dk 2008-06-13 13:01 --- Created an attachment (id=15765) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15765action=view) test.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #5 from benny at ammitzboell-consult dot dk 2008-06-13 13:01 --- Created an attachment (id=15766) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15766action=view) testcpp.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/36527] gcc 4.2.x generates wrong code for ARM target
--- Comment #6 from benny at ammitzboell-consult dot dk 2008-06-13 13:01 --- Created an attachment (id=15767) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15767action=view) testcpp.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
[Bug target/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #13 from benny at ammitzboell-consult dot dk 2008-05-20 07:32 --- Ok, we have verified that this bug is not present when using a 4.2.3 arm toolchain. -- benny at ammitzboell-consult dot dk changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug target/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #14 from benny at ammitzboell-consult dot dk 2008-05-20 07:33 --- Verified on gcc 4.2.3 -- benny at ammitzboell-consult dot dk changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug target/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #12 from benny at ammitzboell-consult dot dk 2008-02-28 08:18 --- We have now tried the 4.2.3 version of gcc and it generates the same assembler code (objdump -d) for the example here on both the 32-bit and the 64-bit host. The RTL is still different though, so it seems you're right about it being a target issue. We're trying to build a full toolchain with gcc 4.2.1 to verify that result in a full-blown test on all of our code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug middle-end/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #3 from benny at ammitzboell-consult dot dk 2008-02-25 14:09 --- Created an attachment (id=15224) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15224action=view) Test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug middle-end/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #4 from benny at ammitzboell-consult dot dk 2008-02-25 14:13 --- Created an attachment (id=15225) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15225action=view) Output from arm-gcc -c -dr main.c (32-bit host) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug middle-end/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #5 from benny at ammitzboell-consult dot dk 2008-02-25 14:14 --- Created an attachment (id=15226) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15226action=view) Output from arm-gcc -c -dM main.c (32-bit host) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug middle-end/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #6 from benny at ammitzboell-consult dot dk 2008-02-25 14:21 --- Created an attachment (id=15227) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15227action=view) Output from arm-gcc -c -dr main.c (64-bit host) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug middle-end/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #7 from benny at ammitzboell-consult dot dk 2008-02-25 14:22 --- Created an attachment (id=15228) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15228action=view) Output from arm-gcc -c -dM main.c (64-bit host) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug middle-end/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #8 from benny at ammitzboell-consult dot dk 2008-02-25 14:27 --- Added test program and RTL output from 32-bit host and 64-bit host. Note the difference in the const_int lines: [EMAIL PROTECTED]:~/src/kuss$ diff /home/bla/Desktop/main.c.01.rtl /home/bla/Desktop/main.c.01.rtl_64 7c7 (const_int -4 [0xfffc])) [0 a+0 S4 A32]) --- (const_int -4 [0xfffc])) [0 a+0 S4 A32]) 15c15 (note 6 5 7 0xf7eeb190 NOTE_INSN_BLOCK_BEG) --- (note 6 5 7 0x2ac25dcd19b0 NOTE_INSN_BLOCK_BEG) 29c29 (const_int -4 [0xfffc])) [0 a+0 S4 A32])) -1 (nil) --- (const_int -4 [0xfffc])) [0 a+0 S4 A32])) -1 (nil) 39c39 (expr_list:REG_EH_REGION (const_int -1 [0x]) --- (expr_list:REG_EH_REGION (const_int -1 [0x]) 49c49 (const_int -4 [0xfffc])) [0 a+0 S4 A32])) --- (const_int -4 [0xfffc])) [0 a+0 S4 A32])) 54c54 (const_int -4 [0xfffc])) [0 a+0 S4 A32])) -1 (nil) --- (const_int -4 [0xfffc])) [0 a+0 S4 A32])) -1 (nil) 107c107 (note 32 31 33 0xf7eeb190 NOTE_INSN_BLOCK_END) --- (note 32 31 33 0x2ac25dcd19b0 NOTE_INSN_BLOCK_END) 125d124 Output from 64-bit host arm-gcc -v: Reading specs from /arm-gcc-3/bin/../lib/gcc/arm-uclinux-elf/3.4.6/specs Configured with: /arm-gcc3-source/build_arm-uclinux/gcc-3.4.6/configure --enable-languages=c --disable-libmudflap --disable-nls --enable-long-long --target=arm-uclinux-elf --prefix=/arm-gcc-3/ : (reconfigured) /arm-gcc3-source/build_arm-uclinux/gcc-3.4.6/configure --target=arm-uclinux-elf --prefix=/arm-gcc-3/ --enable-languages=c,c++ --enable-multilib --enable-target-optspace --with-gnu-ld --disable-nls --disable-__cxa_atexit --enable-threads=posix --disable-clocale --enable-long-long --disable-libstdcxx-pch --disable-checking Thread model: posix gcc version 3.4.6 Output from 32-bit host arm-gcc -v: Reading specs from /arm-gcc-3/bin/../lib/gcc/arm-uclinux-elf/3.4.6/specs Configured with: /arm-gcc3-source/build_arm-uclinux/gcc-3.4.6/configure --enable-languages=c --disable-libmudflap --disable-nls --enable-long-long --target=arm-uclinux-elf --host=i686-pc-linux-gnu --prefix=/arm-gcc-3/ : (reconfigured) /arm-gcc3-source/build_arm-uclinux/gcc-3.4.6/configure --target=arm-uclinux-elf --prefix=/arm-gcc-3/ --enable-languages=c,c++ --enable-multilib --enable-target-optspace --with-gnu-ld --disable-nls --disable-__cxa_atexit --enable-threads=posix --disable-clocale --enable-long-long --disable-libstdcxx-pch --disable-checking --host=i686-pc-linux-gnu Thread model: posix gcc version 3.4.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug middle-end/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #9 from benny at ammitzboell-consult dot dk 2008-02-25 14:31 --- (In reply to comment #2) As when you say bigger do you mean the assembly is different sizes? Or do you mean the actually text/data sections are bigger in the object file? The assembly is bigger on the 64-bit host. Because the 64-bit constants get treated as such and generates more assembler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug target/35295] 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
--- Comment #11 from benny at ammitzboell-consult dot dk 2008-02-25 16:02 --- (In reply to comment #10) At first this looks like a target issue. Can you check if a still maintained GCC version is still affected? That would be 4.2.3 for example. Since print-rtl.c in 4.2.3 still contains code like this: fprintf (outfile, HOST_WIDE_INT_PRINT_DEC, XWINT (in_rtx, i)); if (! flag_simple) fprintf (outfile, [ HOST_WIDE_INT_PRINT_HEX ], XWINT (in_rtx, i)); - I am assuming that the (RTL) behavior is the same as in my examples. But are you saying that a later (target) stage should be able to see that this is just a 32-bit const? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
[Bug c/35295] New: 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target
We are cross-compiling to a 32-bit ARM target from both 32-bit and 64-bit PCs. The gcc cross-compiler toolchain (3.4.6) generates valid code in both cases, but the generated code is larger when a 64-bit host is used. We have tracked this down to the following: 1) The RTL is using 64-bit (on the 64-bit host) to represent constants that is calculated as part of the code-generation. Perhaps because print-rtl.c is using HOST_WIDE_INT_xxx in some places. Surely any kind of constant number even in high level RTL should be using the *target* int size and not the host? 2) The 64-bit constants are treated as such and thus generates more assembler instructions to deal with the 64-bit number on the 32-bit target. We have fixed the toolchain with a workaround where -m32 is used to compile the entire toolchain as 32-bit, but I think the correct solution would be to ensure that constants used in the RTL are represented using the target format in stead of the host. As far as I can see from the code (print-rtl.c) the problem is still there in gcc 4.2.3. -- Summary: 64-bit host cross compile to 32-bit target differs from 32-bit host cross compile to 32-bit target Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: benny at ammitzboell-consult dot dk GCC build triplet: i686-pc-linux-gnu / x86_64-unknown-linux-gnu GCC host triplet: i686-pc-linux-gnu / x86_64-unknown-linux-gnu GCC target triplet: arm-uclinux-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
