------- 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
