[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math
cvs-commit at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed May 5 20:58:02 GMT 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234
--- Comment #29 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Eric Botcazou
<ebotcazou@gcc.gnu.org>:
https://gcc.gnu.org/g:e3abcc56d2604b9d2652b615ff9e68981cb7f79e
commit r10-9804-ge3abcc56d2604b9d2652b615ff9e68981cb7f79e
Author: Eric Botcazou <ebotcazou@adacore.com>
Date: Wed May 5 22:48:51 2021 +0200
Fix PR target/100402
This is a regression for 64-bit Windows present from mainline down to the 9
branch and introduced by the fix for PR target/99234. Again SEH, but with
a twist related to the way MinGW implements setjmp/longjmp, which turns out
to be piggybacked on SEH with recent versions of MinGW, i.e. the longjmp
performs a bona-fide unwinding of the stack, because it calls RtlUnwindEx
with the second argument initially passed to setjmp, which is the result of
__builtin_frame_address (0) in the MinGW header file:
define setjmp(BUF) _setjmp((BUF), __builtin_frame_address (0))
This means that we directly expose the frame pointer to the SEH machinery
here (unlike with regular exception handling where we use an intermediate
CFA) and thus that we cannot do whatever we want with it. The old code
would leave it unaligned, i.e. not multiple of 16, whereas the new code
aligns it, but this breaks for some reason; at least it appears that a
.seh_setframe directive with 0 as second argument always works, so the
fix aligns it this way.
gcc/
PR target/100402
* config/i386/i386.c (ix86_compute_frame_layout): For a SEH target,
always return the establisher frame for __builtin_frame_address
(0).
gcc/testsuite/
* gcc.c-torture/execute/20210505-1.c: New test.
More information about the Gcc-bugs
mailing list