[Bug target/100402] [10.3 regression] crash with setjmp/longjmp and SEH

2021-05-05 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Eric Botcazou  ---
> Yes, I can confirm that this fixes the crash with my attached test, and also
> the original non-reduced application (which is gdb).

OK, thanks for testing and for reporting the problem in the first place.

[Bug target/100402] [10.3 regression] crash with setjmp/longjmp and SEH

2021-05-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402

--- Comment #15 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:182dba3fd507487a724090f1c95eea99a1b9ccad

commit r9-9515-g182dba3fd507487a724090f1c95eea99a1b9ccad
Author: Eric Botcazou 
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.

[Bug target/100402] [10.3 regression] crash with setjmp/longjmp and SEH

2021-05-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402

--- Comment #14 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:e3abcc56d2604b9d2652b615ff9e68981cb7f79e

commit r10-9804-ge3abcc56d2604b9d2652b615ff9e68981cb7f79e
Author: Eric Botcazou 
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.

[Bug target/100402] [10.3 regression] crash with setjmp/longjmp and SEH

2021-05-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:e9a8d6852c966e0511f2cfe40224fd81cbeaae24

commit r11-8358-ge9a8d6852c966e0511f2cfe40224fd81cbeaae24
Author: Eric Botcazou 
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.

[Bug target/100402] [10.3 regression] crash with setjmp/longjmp and SEH

2021-05-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:e8d1ca7d2c344a411779892616c423e157f4aea8

commit r12-525-ge8d1ca7d2c344a411779892616c423e157f4aea8
Author: Eric Botcazou 
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.

[Bug target/100402] [10.3 regression] crash with setjmp/longjmp and SEH

2021-05-05 Thread ssbssa at yahoo dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402

--- Comment #11 from Hannes Domani  ---
> Your testcase does not compile with the C compiler:
> 
> Compiling it with the C++ compiler works for me:

Sorry about the c/c++ confusion.


> Created attachment 50754 [details]
> Tentative fix
> 
> Please give it a try if you can rebuild the compiler.

Yes, I can confirm that this fixes the crash with my attached test, and also
the original non-reduced application (which is gdb).

[Bug target/100402] [10.3 regression] crash with setjmp/longjmp and SEH

2021-05-04 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402

--- Comment #10 from Eric Botcazou  ---
Created attachment 50754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50754=edit
Tentative fix

Please give it a try if you can rebuild the compiler.

[Bug target/100402] [10.3 regression] crash with setjmp/longjmp and SEH

2021-05-04 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #9 from Eric Botcazou  ---
Investigating.

[Bug target/100402] [10.3 regression] crash with setjmp/longjmp and SEH

2021-05-04 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402

Eric Botcazou  changed:

   What|Removed |Added

   Target Milestone|--- |10.4
Summary|Crash in longjmp|[10.3 regression] crash
   ||with setjmp/longjmp and SEH