Bug 90458 - [10 regression] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection
Summary: [10 regression] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 8.3.0
: P3 normal
Target Milestone: 11.4
Assignee: Eric Botcazou
URL:
Keywords: ice-on-valid-code
: 97795 102010 108673 (view as bug list)
Depends on:
Blocks: 97795
  Show dependency treegraph
 
Reported: 2019-05-14 10:44 UTC by Karl Cheng
Modified: 2023-02-15 22:56 UTC (History)
10 users (show)

See Also:
Host:
Target: mingw64
Build:
Known to work: 7.5.0
Known to fail: 8.3.0
Last reconfirmed: 2019-05-14 00:00:00


Attachments
Preprocessed minimal test case (150 bytes, text/plain)
2019-05-14 10:44 UTC, Karl Cheng
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Cheng 2019-05-14 10:44:06 UTC
Created attachment 46350 [details]
Preprocessed minimal test case

Forwarded from: https://github.com/msys2/MINGW-packages/issues/5348

When compiling the following C++ file with -fstack-clash-protection, the following error results:

$ g++ -fstack-clash-protection test.cpp    ^
during RTL pass: final
test.cpp:12:1: internal compiler error: in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://sourceforge.net/projects/msys2> for instructions.

This does not occur without the flag enabled. Attached is the preprocessed minimal test case.

$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-8.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 8.3.0 (Rev2, Built by MSYS2 project)
Comment 1 Martin Liška 2019-05-14 12:51:19 UTC
Started with Jeff's r252998.
Comment 2 Jeffrey A. Law 2019-05-16 20:21:16 UTC
So this is an interaction between stack-clash protection and SEH.   I'm not *at all* familiar with SEH, though obviously I know a bit about stack clash.

In general on x86 the compiler handles stack allocation (and probing when stack clash protection is enabled).  However, on Windows targets that stuff is actually handled by calls to __chkstk_ms.

One could easily argue that stack-clash-protection should be a NOP or generate an error in a Windows environment.
Comment 3 Richard Biener 2020-12-09 08:07:54 UTC
IIRC AdaCore did the SEH stuff?  CCing Eric.
Comment 4 Eric Botcazou 2020-12-09 08:22:40 UTC
> In general on x86 the compiler handles stack allocation (and probing when
> stack clash protection is enabled).  However, on Windows targets that stuff
> is actually handled by calls to __chkstk_ms.
> 
> One could easily argue that stack-clash-protection should be a NOP or
> generate an error in a Windows environment.

Right, Windows has been doing stack clash protection since day #1, like for example Tru64, so the option should just be a NOP on Windows.
Comment 5 Andrew Pinski 2021-08-22 07:54:19 UTC
*** Bug 102010 has been marked as a duplicate of this bug. ***
Comment 6 Andrew Pinski 2021-08-22 07:54:41 UTC
*** Bug 97795 has been marked as a duplicate of this bug. ***
Comment 7 Andrew Pinski 2023-02-04 20:22:26 UTC
*** Bug 108673 has been marked as a duplicate of this bug. ***
Comment 8 nightstrike 2023-02-14 21:13:24 UTC
FYI, this is the same as the failure in gcc/testsuite/gcc.dg/stack-check-16.c:

(running this under Wine)

during RTL pass: final
gcc.dg/stack-check-16.c:36:1: internal compiler error: in i386_pe_seh_unwind_emit, at config/i386/winnt.cc:1274^M
0x86f42f i386_pe_seh_unwind_emit(_IO_FILE*, rtx_insn*)^M
        ../../gcc/config/i386/winnt.cc:1274^M
0xbd4d87 final_scan_insn_1^M
        ../../gcc/final.cc:2851^M
0xbd515b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)^M
        ../../gcc/final.cc:2887^M
0xbd5347 final_1^M
        ../../gcc/final.cc:1979^M
0xbd5e36 rest_of_handle_final^M
        ../../gcc/final.cc:4240^M
0xbd5e36 execute^M
        ../../gcc/final.cc:4318^M
Please submit a full bug report, with preprocessed source (by using -freport-bug).^M
Please include the complete backtrace with any bug report.^M
See <https://gcc.gnu.org/bugs/> for instructions.^M
compiler exited with status 1
Comment 9 GCC Commits 2023-02-15 22:33:57 UTC
The master branch has been updated by Eric Botcazou <ebotcazou@gcc.gnu.org>:

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

commit r13-6069-ga5dd99f7ef4fa5f9542851431bdd149a22b87fd2
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Wed Feb 15 23:32:12 2023 +0100

    Fix PR target/90458
    
    This is the incompatibility of -fstack-clash-protection with Windows SEH.
    Now the Windows ports always enable TARGET_STACK_PROBE, which means that
    the stack is always probed (out of line) so -fstack-clash-protection does
    nothing more.
    
    gcc/
            PR target/90458
            * config/i386/i386.cc (ix86_compute_frame_layout): Disable the
            effects of -fstack-clash-protection for TARGET_STACK_PROBE.
            (ix86_expand_prologue): Likewise.
Comment 10 GCC Commits 2023-02-15 22:46:41 UTC
The releases/gcc-12 branch has been updated by Eric Botcazou <ebotcazou@gcc.gnu.org>:

https://gcc.gnu.org/g:25b80834e2ce6725e676ef33fbf0d009b3173955

commit r12-9177-g25b80834e2ce6725e676ef33fbf0d009b3173955
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Wed Feb 15 23:32:12 2023 +0100

    Fix PR target/90458
    
    This is the incompatibility of -fstack-clash-protection with Windows SEH.
    Now the Windows ports always enable TARGET_STACK_PROBE, which means that
    the stack is always probed (out of line) so -fstack-clash-protection does
    nothing more.
    
    gcc/
            PR target/90458
            * config/i386/i386.cc (ix86_compute_frame_layout): Disable the
            effects of -fstack-clash-protection for TARGET_STACK_PROBE.
            (ix86_expand_prologue): Likewise.
Comment 11 GCC Commits 2023-02-15 22:52:29 UTC
The releases/gcc-11 branch has been updated by Eric Botcazou <ebotcazou@gcc.gnu.org>:

https://gcc.gnu.org/g:20c12f40f9b10eb290fcfe4d02f3367842be573a

commit r11-10527-g20c12f40f9b10eb290fcfe4d02f3367842be573a
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Wed Feb 15 23:32:12 2023 +0100

    Fix PR target/90458
    
    This is the incompatibility of -fstack-clash-protection with Windows SEH.
    Now the Windows ports always enable TARGET_STACK_PROBE, which means that
    the stack is always probed (out of line) so -fstack-clash-protection does
    nothing more.
    
    gcc/
            PR target/90458
            * config/i386/i386.c (ix86_compute_frame_layout): Disable the
            effects of -fstack-clash-protection for TARGET_STACK_PROBE.
            (ix86_expand_prologue): Likewise.
Comment 12 Eric Botcazou 2023-02-15 22:55:40 UTC
Fixed on mainline, 12 and 11 branches.