[Bug middle-end/38609] [4.4 Regression]: gcc.c-torture/execute/built-in-setjmp.c execute -O2 and above

["dave dot korn dot cygwin at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #6 from dave dot korn dot cygwin at gmail dot com  2009-01-26 09:58 -------
Hi HP,

(In reply to comment #5)
> Glancing at the assembly and simulator trace (no looking at rtl or tree dumps
> yet), the value of "p" (sp after the first alloca) is somehow lost and after
> the __builtin_longjmp we effectively strcmp (NULL, "test") which FWIW, doesn't
> SEGV in the simulator, but nevertheless obviously doesn't match.
> At the longjmp-receiver, "p" is retrieved for the strcmp call as "move.d
> [$sp+8],$r10", i.e. $r10 = *((char *) $sp + 8), but that's bogus as nothing was
> stored there; "move.d $sp,$r10" (just copying the stack-pointer) would have
> been correct.

  Sounds like this could maybe be a dup of bug 38952, where the frame pointer
is incorrectly calculated when setjmp saves it in the jmp_buf, and therefore
restored to an incorrect value by longjmp.  For a quick test without rebuilding
your compiler, see if "-mpreferred-stack-boundary=2" or "-mno-stackrealign"
fixes the failure in built-in-setjmp.c; if so there's a patch in the PR that
should help.

  cheers,
    DaveK


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38609