[Bug middle-end/64242] Longjmp expansion incorrect

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242

--- Comment #21 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Rainer Orth from comment #20)
> 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.

My latest patch detects this stack corruption with 100% certainty again, see
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00459.html. However sparc has a
custom nonlocal_goto MD pattern which would need fixing too.