https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
Rainer Orth <ro at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ebotcazou at gcc dot gnu.org,
| |ro at gcc dot gnu.org
--- Comment #20 from Rainer Orth <ro at gcc dot gnu.org> ---
The new testcase also FAILs on sparc-sun-solaris2.11 (both 32 and 64-bit):
+FAIL: gcc.c-torture/execute/pr64242.c -O2 execution test
+FAIL: gcc.c-torture/execute/pr64242.c -O2 -flto execution test
+FAIL: gcc.c-torture/execute/pr64242.c -O2 -flto -flto-partition=none
execution test
+FAIL: gcc.c-torture/execute/pr64242.c -O3 -g execution test
+FAIL: gcc.c-torture/execute/pr64242.c -Os execution test
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00000008 in ?? ()
(gdb) where
#0 0x00000008 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Single-stepping, I find that this happens at the very end of main:
1: x/i $pc
=> 0x10de4 <main+268>: return %i7 + 8
(gdb)
0x00010de8 in main ()
at
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/pr64242.c:50
50 return 0;
1: x/i $pc
=> 0x10de8 <main+272>: nop
(gdb)
0x00000008 in ?? ()
1: x/i $pc
=> 0x8: <error: Cannot access memory at address 0x8>
Obviously the stack is corrupted beyond repair. I tried to avoid this by
replacing the return 0 with exit (0) to no avail.
The original testcase (before Jakub's patch) would abort instead:
Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfec7e044 in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0 0xfec7e044 in __lwp_sigqueue () from /lib/libc.so.1
#1 0xfebb9898 in raise () from /lib/libc.so.1
#2 0xfeb8b1d0 in abort () from /lib/libc.so.1
#3 0x00010ce8 in main () at /homes/ro/pr64242.c:27
