We need 1) the configure line and 2) the error message from the compiler.

IIUC the problem consists on the compiler crashing, so no "error message from the compiler".

You can see the full build output here:

https://github.com/msys2/MINGW-packages/pull/8320/checks?check_run_id=2534098704

As for the configure line, it is not shown on the build output, I'll try to get it from elsewhere. Meanwhile, you can look at the relevant point of the build script here:

https://github.com/msys2/MINGW-packages/blob/134b37fb4bc9b395615cfdf701aeb0635c54fa1a/mingw-w64-gcc/PKGBUILD#L197

We definitely cannot investigate this without more information, in particular the configure line.  Barring that, you might want to try with the current gcc-11 branch where a very recent change could help.

(In reply to Eric Botcazou from comment #3)
> We definitely cannot investigate this without more information, in
> particular the configure line.  Barring that, you might want to try with the
> current gcc-11 branch where a very recent change could help.

Which change? 014e6aa467b1648d09eab9897ca367bfec5e6b76 ? Applying that on top of gcc 11.1 makes no difference.

Sorry for not providing the configure line yet. I'll try to setup a local build environment ASAP.

Taken from config.log:

ac_cs_config=" '--prefix=/mingw32' '--with-local-prefix=/mingw32/local' '--build=i686-w64-mingw32' '--host=i686-w64-mingw32' '--target=i686-w64-mingw32' '--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include' '--libexecdir=/mingw32/lib' '--enable-bootstrap' '--enable-checking=release' '--with-arch=i686' '--with-tune=generic' '--enable-shared' '--enable-static' '--enable-libatomic' '--enable-threads=posix' '--enable-graphite' '--enable-fully-dynamic-string' '--enable-libstdcxx-filesystem-ts' '--enable-libstdcxx-time' '--disable-libstdcxx-pch' '--disable-libstdcxx-debug' '--enable-lto' '--enable-libgomp' '--disable-multilib' '--disable-rpath' '--disable-win32-registry' '--disable-nls' '--disable-werror' '--disable-symvers' '--with-libiconv' '--with-system-zlib' '--with-gmp=/mingw32' '--with-mpfr=/mingw32' '--with-mpc=/mingw32' '--with-isl=/mingw32' '--with-pkgversion=Rev1, Built by MSYS2 project' '--with-bugurl=https://github.com/msys2/MINGW-packages/issues' '--with-gnu-as' '--with-gnu-ld' '--with-boot-ldflags=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc' 'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware' '--enable-linker-plugin-flags=LDFLAGS=-static-libstdc++\\ -static-libgcc\\ -pipe\\ -Wl,--dynamicbase,--nxcompat,--no-seh\\ -Wl,--large-address-aware\\ -Wl,--stack,12582912' '--disable-sjlj-exceptions' '--with-dwarf2' 'build_alias=i686-w64-mingw32' 'host_alias=i686-w64-mingw32' 'target_alias=i686-w64-mingw32' 'CC=gcc' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe' 'LDFLAGS=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware -Wl,--disable-dynamicbase' 'CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1' 'CXX=g++' 'CXXFLAGS=-march=i686 -mtune=generic -O2 -pipe' '--enable-languages=c,ada,c++,fortran,jit,lto,objc,obj-c++'"

Thanks.

> '--with-bugurl=https://github.com/msys2/MINGW-packages/issues'
> '--with-gnu-as' '--with-gnu-ld' '--with-boot-ldflags=-pipe
> -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware
> -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc'
> 'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh
> -Wl,--large-address-aware'
> '--enable-linker-plugin-flags=LDFLAGS=-static-libstdc++\\ -static-libgcc\\
> -pipe\\ -Wl,--dynamicbase,--nxcompat,--no-seh\\ -Wl,--large-address-aware\\
> -Wl,--stack,12582912' '--disable-sjlj-exceptions' '--with-dwarf2'
> 'build_alias=i686-w64-mingw32' 'host_alias=i686-w64-mingw32'
> 'target_alias=i686-w64-mingw32' 'CC=gcc' 'CFLAGS=-march=i686 -mtune=generic
> -O2 -pipe' 'LDFLAGS=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh
> -Wl,--large-address-aware -Wl,--disable-dynamicbase'
> 'CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1' 'CXX=g++' 'CXXFLAGS=-march=i686
> -mtune=generic -O2 -pipe'
> '--enable-languages=c,ada,c++,fortran,jit,lto,objc,obj-c++'"

AFAICS the failure occurs during stage #2 so the stage #1 compiler might be miscompiled by the base compiler.  Could you change the -O2 into -O1 above?
If this still does not work, could you change it into -O0?

make BOOT_CFLAGS='-O1' V=1 all

make BOOT_CFLAGS='-O0' V=1

both fails the same way as the initial report.


export CFLAGS="-march=i686 -mtune=generic -O0 -pipe"
export CXXFLAGS="-march=i686 -mtune=generic -O0 -pipe"
make BOOT_CFLAGS='-O0' V=1

fails on

     configure: error: unsupported system, cannot find sizeof (omp_lock_t)
     make[2]: *** [Makefile:24035: configure-stage1-target-libgomp] Error 1

(this is before the build reaches the failure point discussed on this bug report).


Finally, trying to reduce as much as possible the optimization passes:

export CFLAGS="-march=i686 -mtune=generic -Og -pipe"
export CXXFLAGS="-march=i686 -mtune=generic -Og -pipe"
make BOOT_CFLAGS='-Og' V=1

fails the same way as the initial report.

> make BOOT_CFLAGS='-O1' V=1 all
> 
> make BOOT_CFLAGS='-O0' V=1
> 
> both fails the same way as the initial report.

That's not what I was asking for though, BOOT_CFLAGS should generally not be fiddled with.

> Finally, trying to reduce as much as possible the optimization passes:
> 
> export CFLAGS="-march=i686 -mtune=generic -Og -pipe"
> export CXXFLAGS="-march=i686 -mtune=generic -Og -pipe"
> make BOOT_CFLAGS='-Og' V=1

What happens if you do not set any of CFLAGS/CXXFLAGS/BOOT_CFLAGS?

With those variables unset the build fails the same.

Other users reported that only DWARF crashes. If the build is configured for SJLJ or SEH exception models, it completes.

A user speculated that the problem might be related to Gcc 11 using DWARF 5 now. If you think that that is plausible and instruct me on how to revert that change I'll test the hypothesis.

Setting CFLAGS/CXXFLAGS/BOOT_CFLAGS to -dwarf-4 has no effect: the build fails the same.

> Other users reported that only DWARF crashes. If the build is configured for
> SJLJ or SEH exception models, it completes.
> 
> A user speculated that the problem might be related to Gcc 11 using DWARF 5
> now. If you think that that is plausible and instruct me on how to revert
> that change I'll test the hypothesis.

We do have successful builds (DWARF EH + DWARF 5), that's why I'm trying to understand what's different in your setup.  Do you really have no other failure message than the one output by 'make'?

I don't see other failure messages on the previous dozens of lines but, if they exist, they are not deemed serious enough to stop the build by the build system.

BTW, we successfully built gcc-11-dwarf with gcc-10-sjlj. Now we will see if the resulting binaries work for bootstrapping gcc-11. That would suggest that there is a problem with 10 and it is fixed/masked/whatever on 11.

sadly the successfull build of gcc-11 with dwarf exceptions cannot bootstrap gcc-11 as well, though it now fails even in stage 1 the error is different and seems to be equal to one encountered several years back with gcc-4.1.0 ->

TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h config/i386/xm-mingw32.h" DEFINES="USED_FOR_TARGET " \
/bin/sh ../../gcc-11.1.0/gcc/mkconfig.sh tconfig.h
gnatmake: "xsinfo.adb" compilation error
echo "   S0 : constant String := \"/mingw32/\";" >>tmp-sdefault.adb
cat ../../gcc-11.1.0/gcc/config/i386/gmm_malloc.h > mm_malloc.h
/bin/sh: line 1: ./xsinfo: No such file or directory
(echo "@set version-GCC 11.1.0"; \
 if [ "" = "experimental" ]; \
 then echo "@set DEVELOPMENT"; \
 else echo "@clear DEVELOPMENT"; \
 fi) > gcc-vers.texiT
make[3]: *** [../../gcc-11.1.0/gcc/ada/Make-generated.in:45: ada/sinfo.h] Error 127
make[3]: *** Waiting for unfinished jobs....

Now that GCC 11.2 and binutils 2.37 are out, could you retry with them?

Still the same error with GCC 11.2 and binutils 2.37: https://github.com/msys2/MINGW-packages/pull/9088/checks?check_run_id=3196226530

With g++ 11.2 mingw-w64-i686 a simple test like this crashes:

int main() {
  try {
    throw 13;
  }
  catch(...) {
    return 1;
  }
  return 0;
}

$ g++ foo.cpp
$ ./a.exe
terminate called after throwing an instance of 'int'
terminate called recursively


The configure command is the same mentioned in comment 5, sans Ada.

Thanks for the data point.  We have a working 11.2 compiler on the same platform configured with:

../src/configure --enable-languages=ada,c,c++ --enable-checking=release --enable-threads=win32 --enable-lto --enable-large-address-aware --with-fpmath=sse --disable-sjlj-exceptions --enable-frame-pointer --disable-nls --disable-libstdcxx-pch --disable-libada --enable-libstdcxx

Would it be possible for you to add --enable-frame-pointer to the options?

Adding --enable-frame-pointer makes no difference. No change either adding

--enable-large-address-aware --with-fpmath=sse --disable-sjlj-exceptions --enable-frame-pointer --disable-libada --enable-libstdcxx

Another data point: for the test mentioned on Comment 16, if I replace libstdc++.dll with the same file from gcc 10, the test works.

When I say that --enable-frame-pointer makes no difference, I'm talking about the build failure that prompted this bug report. The build still fails with

  /C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc -B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/ -B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg  -W -Wall -g -O1 -fno-inline \
   -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface -I../../gcc-11.2.0/gcc/ada -I../../gcc-11.2.0/gcc/ada/gcc-interface -Iada/libgnat -I../../gcc-11.2.0/gcc/ada/libgnat ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o

make[3]: *** [../../gcc-11.2.0/gcc/ada/gcc-interface/Make-lang.in:1052: ada/libgnat/a-except.o] Error 1

> Adding --enable-frame-pointer makes no difference. No change either adding
> 
> --enable-large-address-aware --with-fpmath=sse --disable-sjlj-exceptions
> --enable-frame-pointer --disable-libada --enable-libstdcxx
> 
> Another data point: for the test mentioned on Comment 16, if I replace
> libstdc++.dll with the same file from gcc 10, the test works.

Weird, I don't have any dependency on the DLL for it:

$ ldd t.exe
        ntdll.dll => /Windows/SYSTEM32/ntdll.dll (0x7ffc65560000)
        ntdll.dll => /Windows/SysWOW64/ntdll.dll (0x770b0000)
        wow64.dll => /Windows/System32/wow64.dll (0x5d1b0000)
        wow64win.dll => /Windows/System32/wow64win.dll (0x5d210000)

Can you post the output of 'g++ foo.cpp -v' for your C++ testcase?  Can you find out what symbol(s) of libstdc++.dll are referenced by your executable?

(In reply to Eric Botcazou from comment #20)
> Weird, I don't have any dependency on the DLL for it:
> 
> $ ldd t.exe
>         ntdll.dll => /Windows/SYSTEM32/ntdll.dll (0x7ffc65560000)
>         ntdll.dll => /Windows/SysWOW64/ntdll.dll (0x770b0000)
>         wow64.dll => /Windows/System32/wow64.dll (0x5d1b0000)
>         wow64win.dll => /Windows/System32/wow64win.dll (0x5d210000)
> 
> Can you post the output of 'g++ foo.cpp -v' for your C++ testcase?  Can you
> find out what symbol(s) of libstdc++.dll are referenced by your executable?

ldd does not list libstdc++.dll, but `Dependency Walker` lists both libstdc++.dll and libgcc_s_dw2-1.dll.

Imports from libstdc++.dll:

_ZTIi
__cxa_allocate_exception
__cxa_begin_catch
__cxa_end_catch
__cxa_throw
__gxx_personality_v0


Imports from libgcc_s_dw2-1.dll:

__deregister_frame_info
__register_frame_info


$ g++ -v excep.cpp
Using built-in specs.
COLLECT_GCC=D:\dev\other\MINGW-packages\mingw-w64-gcc\pkg\mingw-w64-i686-gcc\mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-11.2.0/configure --prefix=/mingw32 --with-local-prefix=/mingw32/local --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --with-native-system-header-dir=/mingw32/i686-w64-mingw32/include --libexecdir=/mingw32/lib --enable-bootstrap --enable-checking=release --with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++,fortran,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-libstdcxx-debug --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --with-boot-ldflags='-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc' 'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware' --enable-linker-plugin-flags='LDFLAGS=-static-libstdc++\ -static-libgcc\ -pipe\ -Wl,--dynamicbase,--nxcompat,--no-seh\ -Wl,--large-address-aware\ -Wl,--stack,12582912' --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Rev1, Built by MSYS2 project)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=i686' '-dumpdir' 'a-'
 D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/cc1plus.exe -quiet -v -iprefix D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/ -D_REENTRANT excep.cpp -quiet -dumpdir a- -dumpbase excep.cpp -dumpbase-ext .cpp -mtune=generic -march=i686 -version -o C:\apps\msys64\tmp\ccit4tWf.s
GNU C++17 (Rev1, Built by MSYS2 project) version 11.2.0 (i686-w64-mingw32)
        compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/include"
ignoring duplicate directory "D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0"
ignoring duplicate directory "D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/i686-w64-mingw32"
ignoring duplicate directory "D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/backward"
ignoring duplicate directory "D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/include"
ignoring duplicate directory "D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/include-fixed"
ignoring nonexistent directory "D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/11.2.0/../../../../i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0
 D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/i686-w64-mingw32
 D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include/c++/11.2.0/backward
 D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/include
 D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../include
 D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/include-fixed
 C:/apps/msys64/mingw32/lib/gcc/i686-w64-mingw32/../../../include
 /mingw32/include
 C:/apps/msys64/mingw32/i686-w64-mingw32/include
End of search list.
GNU C++17 (Rev1, Built by MSYS2 project) version 11.2.0 (i686-w64-mingw32)
        compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 77b0bd1c0f70954aef7bfe4de77d7651
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=i686' '-dumpdir' 'a-'
 as -v -o C:\apps\msys64\tmp\ccYL7INp.o C:\apps\msys64\tmp\ccit4tWf.s
GNU ensamblador versi▒n 2.37 (i686-w64-mingw32) utilizando BFD versi▒n (GNU Binutils) 2.37
COMPILER_PATH=D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/;D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/
LIBRARY_PATH=D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/;D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/;D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../lib/;C:/apps/msys64/mingw32/i686-w64-mingw32/lib/../lib/;D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../;C:/apps/msys64/mingw32/i686-w64-mingw32/lib/
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=i686' '-dumpdir' 'a.'
 D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/collect2.exe -plugin D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/liblto_plugin.dll -plugin-opt=D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/lto-wrapper.exe -plugin-opt=-fresolution=C:\apps\msys64\tmp\ccB6qlbq.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-lkernel32 -m i386pe -Bdynamic -u ___register_frame_info -u ___deregister_frame_info C:/apps/msys64/mingw32/i686-w64-mingw32/lib/../lib/crt2.o D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/crtbegin.o -LD:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0 -LD:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc -LD:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../../../lib -LC:/apps/msys64/mingw32/i686-w64-mingw32/lib/../lib -LD:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/../../.. -LC:/apps/msys64/mingw32/i686-w64-mingw32/lib C:\apps\msys64\tmp\ccYL7INp.o -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32 -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32 C:/apps/msys64/mingw32/i686-w64-mingw32/lib/../lib/default-manifest.o D:/dev/other/MINGW-packages/mingw-w64-gcc/pkg/mingw-w64-i686-gcc/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.2.0/crtend.o
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=i686' '-dumpdir' 'a.'

> ldd does not list libstdc++.dll, but `Dependency Walker` lists both
> libstdc++.dll and libgcc_s_dw2-1.dll.
> 
> Imports from libstdc++.dll:
> 
> _ZTIi
> __cxa_allocate_exception
> __cxa_begin_catch
> __cxa_end_catch
> __cxa_throw
> __gxx_personality_v0
> 
> 
> Imports from libgcc_s_dw2-1.dll:
> 
> __deregister_frame_info
> __register_frame_info

Yes, I figured out that ldd was not reliable in the meantime.  How nice...

So it looks like exception propagation is broken in your setup and it's hard to guess why without investigating a little.  Of course it's a bit tricky to do, especially on Windows.

Can you upload somewhere a package containing the executable, libgcc_s_dw2-1.dll and libstdc++.dll from GCC 11, as well as libstdc++.dll from GCC 10 and post the URL here?

See http://88.17.68.234/clientes/gcc

It contains the gcc binary packages with debug info, plus packages for dependencies (mpc/gmp/etc.)

It also contains the libstdc++ dll from 10.3 (the "working" one).

The gcc packages are built with the MSYS2 local patches included in the tarfile patches.tgz.

Note that a build without local patches was already tried with the same failure while building Ada.

If the local patches are a problem for you, I'll make a build from stock gcc, but it will take time.

Please let me know if you need something else. Thanks.

Sorry, I misread your message and now realized that you just wanted the executable and its dependencies. They are now on the same URL. The 11.2 libstdc++ and libgcc dlls are built with debug info.

> Sorry, I misread your message and now realized that you just wanted the
> executable and its dependencies. They are now on the same URL. The 11.2
> libstdc++ and libgcc dlls are built with debug info.

Thanks.  I cannot reproduce the problem though:

botcazou@PAWNEE ~
$ cd gcc10/

botcazou@PAWNEE ~/gcc10
$ ./excep.exe 

botcazou@PAWNEE ~/gcc10
$ ls -l
total 2636
-rwxr-xr-x+ 1 botcazou None  111259 Oct 15 09:25 excep.exe
-rwxr-xr-x+ 1 botcazou None  604303 Oct 15 09:23 libgcc_s_dw2-1.dll
-rw-r--r--+ 1 botcazou None 1904773 Oct 15 09:23 libstdc++-6.dll
-rw-r--r--+ 1 botcazou None   69066 Oct 15 09:25 libwinpthread-1.dll

botcazou@PAWNEE ~/gcc10
$ cd ..

botcazou@PAWNEE ~
$ cd gcc11/

botcazou@PAWNEE ~/gcc11
$ ls -l
total 24636
-rwxr-xr-x+ 1 botcazou None   111259 Oct 15 09:25 excep.exe
-rwxr-xr-x+ 1 botcazou None   604303 Oct 15 09:25 libgcc_s_dw2-1.dll
-rwxr-xr-x+ 1 botcazou None 24433712 Oct 15 09:25 libstdc++-6.dll
-rw-r--r--+ 1 botcazou None    69066 Oct 15 09:25 libwinpthread-1.dll

botcazou@PAWNEE ~/gcc11
$ ./excep.exe 

botcazou@PAWNEE ~/gcc11

(In reply to Eric Botcazou from comment #25)
> > Sorry, I misread your message and now realized that you just wanted the
> > executable and its dependencies. They are now on the same URL. The 11.2
> > libstdc++ and libgcc dlls are built with debug info.
> 
> Thanks.  I cannot reproduce the problem though:

Curious. I tested the executable on Windows 10 and on Wine, with same result. Maybe your setup is hiding the output? Or the executable is not being started at all? (I've seen that on some environments where a required dll was missing or was incorrect.)

I uploaded new excep.cpp/excep.exe files. Now the executable should give signs of life before crashing:

$ ./excep.exe
Throwing...

terminate called after throwing an instance of 'int'
terminate called recursively

abnormal program termination


I suggest to try the reproducer under a normal Windows shell, not some MSYS2/Cygwin terminal emulator.

> Curious. I tested the executable on Windows 10 and on Wine, with same
> result. Maybe your setup is hiding the output? Or the executable is not
> being started at all? (I've seen that on some environments where a required
> dll was missing or was incorrect.)

My bad, missing executable bit on the DLLs...

OK, I know what's wrong in the libstdc++.dll of GCC 11, now let's try to figure out why this is so...  Can you run 'nm' on one of the occurrences of crtend.o in the build tree (there are two copies of it)?  On my machine it yields:

00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 d .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 t .text.startup
00000000 d ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor

(In reply to Eric Botcazou from comment #28)
> OK, I know what's wrong in the libstdc++.dll of GCC 11, now let's try to
> figure out why this is so...  Can you run 'nm' on one of the occurrences of
> crtend.o in the build tree (there are two copies of it)?  On my machine it
> yields:
> 
> 00000000 b .bss
> 00000000 d .ctors.65535
> 00000000 d .data
> 00000000 d .eh_frame
> 00000000 r .rdata$zzz
> 00000000 t .text
> 00000000 t .text.startup
> 00000000 d ___FRAME_END__
>          U ___gcc_register_frame
> 00000000 t _register_frame_ctor

I have quite a few crtend.o files in the build directory. A quick glance indicates that .text.startup is missing:

$ for f in `find ./build-i686-w64-mingw32/ -name crtend.o` ; do echo $f && nm $f ; done
./build-i686-w64-mingw32/gcc/crtend.o
00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 r .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 r ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor
./build-i686-w64-mingw32/i686-w64-mingw32/libgcc/crtend.o
00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 r .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 r ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor
./build-i686-w64-mingw32/prev-gcc/crtend.o
00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 r .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 r ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor
./build-i686-w64-mingw32/prev-i686-w64-mingw32/libgcc/crtend.o
00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 r .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 r ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor
./build-i686-w64-mingw32/stage1-gcc/crtend.o
00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 r .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 r ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor
./build-i686-w64-mingw32/stage1-i686-w64-mingw32/libgcc/crtend.o
00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 r .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 r ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor



These are the crtend.o from the installed gcc 10.3 (which works fine):

$ for f in `find /mingw32 -name crtend.o` ; do echo $f && nm $f ; done          /mingw32/i686-w64-mingw32/lib/crtend.o
00000000 b .bss
00000000 d .data
00000000 r .rdata$zzz
00000000 t .text
/mingw32/lib/gcc/i686-w64-mingw32/10.3.0/crtend.o
00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 r .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 t .text.startup
00000000 r ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor

> I have quite a few crtend.o files in the build directory. A quick glance
> indicates that .text.startup is missing:
> 
> $ for f in `find ./build-i686-w64-mingw32/ -name crtend.o` ; do echo $f &&
> nm $f ; done
> ./build-i686-w64-mingw32/gcc/crtend.o
> 00000000 b .bss
> 00000000 d .ctors.65535
> 00000000 d .data
> 00000000 r .eh_frame
> 00000000 r .rdata$zzz
> 00000000 t .text
> 00000000 r ___FRAME_END__
>          U ___gcc_register_frame
> 00000000 t _register_frame_ctor

Yep, that is suspicious, this might indicate that:

static void register_frame_ctor (void) __attribute__ ((constructor (0)));

is not considered a static constructor.

Could you replay the compilation of this file?  In the top level directory, do
  rm i686-w64-mingw32/libgcc/crtend.o
  make all-target-libgcc
copy the (long) command line, go into the i686-w64-mingw32/libgcc directory and execute it after adding -save-temps to it.  You should get a small assembly file named crtend.s and I would be interested in its contents.

> Could you replay the compilation of this file?  In the top level directory,
> do
>   rm i686-w64-mingw32/libgcc/crtend.o
>   make all-target-libgcc
> copy the (long) command line, go into the i686-w64-mingw32/libgcc directory
> and execute it after adding -save-temps to it.  You should get a small
> assembly file named crtend.s and I would be interested in its contents.

The compilation emits this warning:

../../../gcc-11.2.0/libgcc/config/i386/cygming-crtend.c:59:1: warning: constructor priorities from 0 to 100 are reserved for the implementation [-Wprio-ctor-dtor]
   59 | static void register_frame_ctor (void) __attribute__ ((constructor (0)));
      | ^~~~~~


Contents of crtend.s:

$ cat crtend.s
        .file   "cygming-crtend.c"
        .text
        .section        .eh_frame,"w"
        .align 4
___FRAME_END__:
        .space 4
        .text
        .def    _register_frame_ctor;   .scl    3;      .type   32;     .endef
_register_frame_ctor:
LFB55:
        .cfi_startproc
        pushl   %ebp
        .cfi_def_cfa_offset 8
        .cfi_offset 5, -8
        movl    %esp, %ebp
        .cfi_def_cfa_register 5
        subl    $8, %esp
        call    ___gcc_register_frame
        leave
        .cfi_restore 5
        .cfi_def_cfa 4, 4
        ret
        .cfi_endproc
LFE55:
        .section        .ctors.65535,"w"
        .align 4
        .long   _register_frame_ctor
        .ident  "GCC: (Rev1, Built by MSYS2 project) 11.2.0"
        .def    ___gcc_register_frame;  .scl    2;      .type   32;     .endef

> The compilation emits this warning:
> 
> ../../../gcc-11.2.0/libgcc/config/i386/cygming-crtend.c:59:1: warning:
> constructor priorities from 0 to 100 are reserved for the implementation
> [-Wprio-ctor-dtor]
>    59 | static void register_frame_ctor (void) __attribute__ ((constructor
> (0)));
>       | ^~~~~~

Yes, expected.

> Contents of crtend.s:
> 
> $ cat crtend.s
>         .file   "cygming-crtend.c"
>         .text
>         .section        .eh_frame,"w"
>         .align 4
> ___FRAME_END__:
>         .space 4
>         .text
>         .def    _register_frame_ctor;   .scl    3;      .type   32;    
> .endef
> _register_frame_ctor:
> LFB55:
>         .cfi_startproc
>         pushl   %ebp
>         .cfi_def_cfa_offset 8
>         .cfi_offset 5, -8
>         movl    %esp, %ebp
>         .cfi_def_cfa_register 5
>         subl    $8, %esp
>         call    ___gcc_register_frame
>         leave
>         .cfi_restore 5
>         .cfi_def_cfa 4, 4
>         ret
>         .cfi_endproc
> LFE55:
>         .section        .ctors.65535,"w"
>         .align 4
>         .long   _register_frame_ctor
>         .ident  "GCC: (Rev1, Built by MSYS2 project) 11.2.0"
>         .def    ___gcc_register_frame;  .scl    2;      .type   32;    
> .endef

Weird, this looks like a compilation at -O0.  Can you post the command line?

> Weird, this looks like a compilation at -O0.  Can you post the command line?

-O1 gives the same assembly.

> These are the crtend.o from the installed gcc 10.3 (which works fine):
> 
> $ for f in `find /mingw32 -name crtend.o` ; do echo $f && nm $f ; done      
> /mingw32/i686-w64-mingw32/lib/crtend.o
> 00000000 b .bss
> 00000000 d .data
> 00000000 r .rdata$zzz
> 00000000 t .text

Where does this one come from exactly?  It looks totally empty.

Yes, it is a debug build (the libstdc++ dll you got is from that). The same crash happens with a release build, though.

Note the -Og going after the -O2:

/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include    -g -march=pentium4 -mtune=generic -O2 -pipe -ggdb -Og -fdebug-prefix-map=/d/dev/other/MINGW-packages/mingw-w64-gcc/src=/usr/src/debug -O2 -g -march=pentium4 -mtune=generic -O2 -pipe -ggdb -Og -fdebug-prefix-map=/d/dev/other/MINGW-packages/mingw-w64-gcc/src=/usr/src/debug -DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition  -isystem ./include  -I. -I. -I../.././gcc -I../../../gcc-11.2.0/libgcc -I../../../gcc-11.2.0/libgcc/. -I../../../gcc-11.2.0/libgcc/../gcc -I../../../gcc-11.2.0/libgcc/../include -I../../../gcc-11.2.0/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT  -g0  -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector    -I. -I. -I../.././gcc -I../../../gcc-11.2.0/libgcc -I../../../gcc-11.2.0/libgcc/. -I../../../gcc-11.2.0/libgcc/../gcc -I../../../gcc-11.2.0/libgcc/../include -I../../../gcc-11.2.0/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -o crtend.o -MT crtend.o -MD -MP -MF crtend.dep -fno-omit-frame-pointer -Wno-error -c ../../../gcc-11.2.0/libgcc/config/i386/cygming-crtend.c

(In reply to Eric Botcazou from comment #34)
> > These are the crtend.o from the installed gcc 10.3 (which works fine):
> > 
> > $ for f in `find /mingw32 -name crtend.o` ; do echo $f && nm $f ; done      
> > /mingw32/i686-w64-mingw32/lib/crtend.o
> > 00000000 b .bss
> > 00000000 d .data
> > 00000000 r .rdata$zzz
> > 00000000 t .text
> 
> Where does this one come from exactly?  It looks totally empty.

It comes from the MinGW-w64 CRT.

> It comes from the MinGW-w64 CRT.

We do not have it.  Can you (temporarily) remove it and see what happens?

(In reply to Eric Botcazou from comment #37)
> > It comes from the MinGW-w64 CRT.
> 
> We do not have it.  Can you (temporarily) remove it and see what happens?

After moving away that file, exceptions still are broken, but that can be due to a tainted libstdc++ dll.

Do you want a full rebuild of gcc?

> We do not have it.  Can you (temporarily) remove it and see what happens?

In fact we specifically remove them at packaging time:

        # Remove crtbegin.o and crtend.o. We are rebuilding them during
        # GCC builds
        rm(os.path.join(self["PKG_DIR"], "lib", "crtbegin.o"))
        rm(os.path.join(self["PKG_DIR"], "lib", "crtend.o"))

> Do you want a full rebuild of gcc?

At least a full rebuild of libstdc++-v3:
  rm -rf i686-w64-mingw32/libstdc++-v3
  make all-target-libstdc++-v3 -jN

(In reply to Eric Botcazou from comment #40)
> > Do you want a full rebuild of gcc?
> 
> At least a full rebuild of libstdc++-v3:
>   rm -rf i686-w64-mingw32/libstdc++-v3
>   make all-target-libstdc++-v3 -jN

After removing the spurious crtend.o and rebuilding libstdc++ following those instructions, the new libstdc++-6.dll still crashes the same way.

> After removing the spurious crtend.o and rebuilding libstdc++ following
> those instructions, the new libstdc++-6.dll still crashes the same way.

Can you remove the crtbegin.o too, just to be sure, rebuild libstdc++ and upload the DLL at the same URL as before?

(In reply to Eric Botcazou from comment #42)
> Can you remove the crtbegin.o too, just to be sure, rebuild libstdc++ and
> upload the DLL at the same URL as before?

Same result after moving away crtbegin.o. DLL uploaded with name

libstdc++-6.dll.without-crt-begin-end

Fore completeness: The "exceptions not working" problem now also crept into our v10.3 build with the last rebuild. Maybe some dependency change in the last two months, but no idea :/

https://github.com/msys2/MINGW-packages/issues/9771

So this isn't something new in v11

> Fore completeness: The "exceptions not working" problem now also crept into
> our v10.3 build with the last rebuild. Maybe some dependency change in the
> last two months, but no idea :/
> 
> https://github.com/msys2/MINGW-packages/issues/9771

Can you confirm that this is with the same compiler sources as the previous 10.3 version that works?  Do you apply local changes to them?

(In reply to Eric Botcazou from comment #45)
> > Fore completeness: The "exceptions not working" problem now also crept into
> > our v10.3 build with the last rebuild. Maybe some dependency change in the
> > last two months, but no idea :/
> > 
> > https://github.com/msys2/MINGW-packages/issues/9771
> 
> Can you confirm that this is with the same compiler sources as the previous
> 10.3 version that works?  Do you apply local changes to them?

Yes, everything is checksummed in our build script. We apply various patches and backports, they are also checksummed: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD

> Yes, everything is checksummed in our build script. We apply various patches
> and backports, they are also checksummed:
> https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD

Did you change binutils, in particular the linker, in between?

(In reply to Eric Botcazou from comment #47)
> > Yes, everything is checksummed in our build script. We apply various patches
> > and backports, they are also checksummed:
> > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD
> 
> Did you change binutils, in particular the linker, in between?

Yes, from 2.36.1 to 2.37, but I've already tried reverting that and it didn't help. I'm going to try older versions (of everything) though..

> Fore completeness: The "exceptions not working" problem now also crept into
> our v10.3 build with the last rebuild. Maybe some dependency change in the
> last two months, but no idea :/
> 
> https://github.com/msys2/MINGW-packages/issues/9771

I can confirm that the libstdc++ DLL available from there is broken in exactly the same way as the one from GCC 11: it fails to register its unwinding tables, i.e. the call to __register_frame_info on startup is missing.  That's managed by the pair of crtbegin.o/ctrend.o object files from the compiler but the intermediate __gcc_register_frame is never called.

> Yes, from 2.36.1 to 2.37, but I've already tried reverting that and it
> didn't help. I'm going to try older versions (of everything) though..

This could as well be a miscompilation of the linker.  Can you upload ld.exe somewhere so that I replace mine with it?

(In reply to Eric Botcazou from comment #50)
> > Yes, from 2.36.1 to 2.37, but I've already tried reverting that and it
> > didn't help. I'm going to try older versions (of everything) though..
> 
> This could as well be a miscompilation of the linker.  Can you upload ld.exe
> somewhere so that I replace mine with it?

If you happen to have an tool that supports extracting .tar.zst you could take the .exe from package directly: https://repo.msys2.org/mingw/mingw32/mingw-w64-i686-binutils-2.37-4-any.pkg.tar.zst

Turns out this might be fallout from the last grep update, see https://github.com/msys2/MINGW-packages/issues/9771#issuecomment-945007372 Needs investigating..

(In reply to Christoph Reiter from comment #52)
> Turns out this might be fallout from the last grep update, see
> https://github.com/msys2/MINGW-packages/issues/9771#issuecomment-945007372
> Needs investigating..

"this" means the problem with C++ exceptions, which indeed is fixed by building gcc after reverting to grep 3.0.

The build failure with Ada, which predated the grep upgrade, persists.

Eric: I'm sorry for the time you wasted on this wild goose chase.

> "this" means the problem with C++ exceptions, which indeed is fixed by
> building gcc after reverting to grep 3.0.
> 
> The build failure with Ada, which predated the grep upgrade, persists.
> 
> Eric: I'm sorry for the time you wasted on this wild goose chase.

No problem, I already wasted more time in other circumstances...

So we're back to square one with the Ada-specific problem.  At this point a backtrace would really be needed because our environments are quite different.

According to the initial report, the problem occurs during stage #2 compiling ada/libgnat/a-except.adb, so one would need to go into the gcc/ subdirectory of the build tree and replay the command line:

/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc -B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/ -B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg  -W -Wall -g -O1 -fno-inline \
2021-05-08T11:34:54.9009139Z  -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface -I../../gcc-11.1.0/gcc/ada -I../../gcc-11.1.0/gcc/ada/gcc-interface -Iada/libgnat -I../../gcc-11.1.0/gcc/ada/libgnat ../../gcc-11.1.0/gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o

after appending -wrapper gdb,--args to it.  This should launch an interactive GDB session for gcc/gnat1 with the above command line.  Then 'catch exception' and 'run' might reveal what happens.

Here we go (this is a debug build):

$ /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc -B/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/ -B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg  -W -Wall -g -O1 -fno-inline  -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface -I../../gcc-11.2.0/gcc/ada -I../../gcc-11.2.0/gcc/ada/gcc-interface -Iada/libgnat -I../../gcc-11.2.0/gcc/ada/libgnat ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o -wrapper gdb,--args
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from D:/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-gcc/gnat1.exe...
Breakpoint 1 at 0x1b9b938: file ../../gcc-11.2.0/gcc/diagnostic.c, line 1884.
Breakpoint 2 at 0x1b9b79f: file ../../gcc-11.2.0/gcc/diagnostic.c, line 1804.
Breakpoint 3 at 0x1e3b618
Breakpoint 4 at 0x1e3b5e8
File tree.h will be skipped when stepping.
File is-a.h will be skipped when stepping.
File line-map.h will be skipped when stepping.
File timevar.h will be skipped when stepping.
Function rtx_expr_list::next will be skipped when stepping.
Function rtx_expr_list::element will be skipped when stepping.
Function rtx_insn_list::next will be skipped when stepping.
Function rtx_insn_list::insn will be skipped when stepping.
Function rtx_sequence::len will be skipped when stepping.
Function rtx_sequence::element will be skipped when stepping.
Function rtx_sequence::insn will be skipped when stepping.
Function INSN_UID will be skipped when stepping.
Function PREV_INSN will be skipped when stepping.
Function SET_PREV_INSN will be skipped when stepping.
Function NEXT_INSN will be skipped when stepping.
Function SET_NEXT_INSN will be skipped when stepping.
Function BLOCK_FOR_INSN will be skipped when stepping.
Function PATTERN will be skipped when stepping.
Function INSN_LOCATION will be skipped when stepping.
Function INSN_HAS_LOCATION will be skipped when stepping.
Function JUMP_LABEL_AS_INSN will be skipped when stepping.
Successfully loaded GDB hooks for GCC
(gdb) catch exception
Catchpoint 5: all Ada exceptions
(gdb) run
Starting program: D:\dev\other\MINGW-packages\mingw-w64-gcc\src\build-i686-w64-mingw32\prev-gcc\gnat1.exe -I - -I . -I ada/generated -I ada -I ada/gcc-interface -I ../../gcc-11.2.0/gcc/ada -I ../../gcc-11.2.0/gcc/ada/gcc-interface -I ada/libgnat -I ../../gcc-11.2.0/gcc/ada/libgnat -gnatwa -quiet -nostdinc -O2 -O1 -Wno-pedantic-ms-format -Wextra -Wall -dumpdir ada/libgnat/ -dumpbase a-except.adb -dumpbase-ext .adb -g -fno-checking -gtoggle -gnatpg -g -fno-inline "-mtune=generic" "-march=i686" -gnatO ada/libgnat/a-except.o ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb -o C:\apps\msys64\tmp\ccyhgK0H.s
[New Thread 4320.0x1d80]
[New Thread 4320.0x1d04]
[New Thread 4320.0x2010]
gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada

Catchpoint 5, SEM_PRAG.ANALYZE_PRAGMA.PRAGMA_EXIT (sem_prag.adb:6605) at 0x007e816c in sem_prag.analyze_pragma.check_valid_library_unit_pragma ()
    at ../../gcc-11.2.0/gcc/ada/sem_prag.adb:6605
6605                      raise Pragma_Exit;
(gdb) bt
#0  <__gnat_debug_raise_exception> (
    e=0x207a990 <sem_prag.analyze_pragma.pragma_exit>, message=...)
    at ../../gcc-11.2.0/gcc/ada/libgnat/s-excdeb.adb:40
#1  0x0048e862 in ada.exceptions.complete_occurrence (x=x@entry=0x132d8ac0)
    at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:912
#2  0x0048e878 in ada.exceptions.complete_and_propagate_occurrence (
    x=x@entry=0x132d8ac0) at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:923
#3  0x0048e8b3 in <__gnat_raise_exception> (
    e=0x207a990 <sem_prag.analyze_pragma.pragma_exit>, message=...)
    at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:960
#4  0x007e816c in sem_prag.analyze_pragma.check_valid_library_unit_pragma ()
    at ../../gcc-11.2.0/gcc/ada/sem_prag.adb:6605
#5  0x007deae3 in sem_prag.analyze_pragma (n=33616)
    at ../../gcc-11.2.0/gcc/ada/sem_prag.adb:21911
#6  0x006a1445 in sem.analyze (n=33616)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:465
#7  0x007186da in sem_ch3.analyze_declarations (l=-99996169)
    at ../../gcc-11.2.0/gcc/ada/sem_ch3.adb:2655
#8  0x00770b7d in sem_ch7.analyze_package_specification (n=33606)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:1582
#9  0x006a1425 in sem.analyze (n=33606)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:459
#10 0x00770856 in sem_ch7.analyze_package_declaration (n=33729)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:1210
#11 0x006a13f5 in sem.analyze (n=33729)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:450
#12 0x006deab8 in sem_ch12.analyze_package_instantiation (n=33272)
    at ../../gcc-11.2.0/gcc/ada/sem_ch12.adb:4773
#13 0x006a1405 in sem.analyze (n=33272)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:453
#14 0x007186da in sem_ch3.analyze_declarations (l=-99996197)
    at ../../gcc-11.2.0/gcc/ada/sem_ch3.adb:2655
#15 0x00770b7d in sem_ch7.analyze_package_specification (n=33260)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:1582
#16 0x006a1425 in sem.analyze (n=33260)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:459
#17 0x00770856 in sem_ch7.analyze_package_declaration (n=33354)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:1210
#18 0x006a13f5 in sem.analyze (n=33354)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:450
#19 0x006cbb45 in sem_ch10.analyze_compilation_unit (n=33243)
    at ../../gcc-11.2.0/gcc/ada/sem_ch10.adb:913
#20 0x006a0e55 in sem.analyze (n=33243)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:180
#21 0x006a24b9 in sem.semantics.do_analyze ()
    at ../../gcc-11.2.0/gcc/ada/sem.adb:1421
#22 0x006a292d in sem.semantics (comp_unit=33243)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:1615
#23 0x00687752 in rtsfind.load_rtu (u_id=system_img_int, id=re_image_integer,
    use_setting=false) at ../../gcc-11.2.0/gcc/ada/rtsfind.adb:1156
#24 0x0068838a in rtsfind.rte (e=re_image_integer)
    at ../../gcc-11.2.0/gcc/ada/rtsfind.adb:1506
#25 0x005bd859 in exp_imgv.expand_image_attribute (n=6229)
    at ../../gcc-11.2.0/gcc/ada/exp_imgv.adb:750
#26 0x0050e140 in exp_attr.expand_n_attribute_reference (n=6229)
    at ../../gcc-11.2.0/gcc/ada/exp_attr.adb:3931
#27 0x005ed275 in expander.expand (n=6229)
    at ../../gcc-11.2.0/gcc/ada/expander.adb:205
#28 0x00802c25 in sem_res.resolve (n=6229, typ=128)
    at ../../gcc-11.2.0/gcc/ada/sem_res.adb:3399
#29 0x0071b2f5 in sem_ch3.analyze_object_declaration (n=6226)
    at ../../gcc-11.2.0/gcc/ada/sem_ch3.adb:4302
#30 0x006a11e5 in sem.analyze (n=6226) at ../../gcc-11.2.0/gcc/ada/sem.adb:351
#31 0x007186da in sem_ch3.analyze_declarations (l=-99999533)
    at ../../gcc-11.2.0/gcc/ada/sem_ch3.adb:2655
#32 0x0075e2ca in sem_ch6.analyze_subprogram_body_helper (n=6217)
    at ../../gcc-11.2.0/gcc/ada/sem_ch6.adb:5156
#33 0x0075c568 in sem_ch6.analyze_subprogram_body (n=6217)
    at ../../gcc-11.2.0/gcc/ada/sem_ch6.adb:2818
#34 0x006a15fd in sem.analyze (n=6217) at ../../gcc-11.2.0/gcc/ada/sem.adb:547
#35 0x007186da in sem_ch3.analyze_declarations (l=-99999978)
    at ../../gcc-11.2.0/gcc/ada/sem_ch3.adb:2655
#36 0x0076f8db in sem_ch7.analyze_package_body_helper (n=2413)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:954
#37 0x0076ee0a in sem_ch7.analyze_package_body (n=2413)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:180
#38 0x006a13d5 in sem.analyze (n=2413) at ../../gcc-11.2.0/gcc/ada/sem.adb:444
#39 0x006cbb45 in sem_ch10.analyze_compilation_unit (n=2335)
    at ../../gcc-11.2.0/gcc/ada/sem_ch10.adb:913
#40 0x006a0e55 in sem.analyze (n=2335) at ../../gcc-11.2.0/gcc/ada/sem.adb:180
#41 0x006a24b9 in sem.semantics.do_analyze ()
    at ../../gcc-11.2.0/gcc/ada/sem.adb:1421
#42 0x006a292d in sem.semantics (comp_unit=2335)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:1615
#43 0x00604842 in frontend () at ../../gcc-11.2.0/gcc/ada/frontend.adb:422
#44 0x0089b6d9 in gnat1drv () at ../../gcc-11.2.0/gcc/ada/gnat1drv.adb:1237
#45 0x004243d4 in gnat_parse_file ()
    at ../../gcc-11.2.0/gcc/ada/gcc-interface/misc.c:118
#46 0x00d994a8 in compile_file () at ../../gcc-11.2.0/gcc/toplev.c:457
#47 0x00d9c382 in do_compile () at ../../gcc-11.2.0/gcc/toplev.c:2201
#48 0x00d9c66f in toplev::main (this=0x1070febe, argc=46, argv=0x12e11e40)
    at ../../gcc-11.2.0/gcc/toplev.c:2340
#49 0x01b7a6ab in main (argc=46, argv=0x12e11e40)
    at ../../gcc-11.2.0/gcc/main.c:39
(gdb) c
Continuing.

Thread 1 hit Breakpoint 4, 0x773bb68b in msvcrt!abort ()
   from C:\WINDOWS\SysWOW64\msvcrt.dll
(gdb) bt
#0  0x773bb68b in msvcrt!abort () from C:\WINDOWS\SysWOW64\msvcrt.dll
#1  0x02074f7d in uw_init_context_1 (context=context@entry=0x1070c890,
    outer_cfa=outer_cfa@entry=0x1070ca70,
    outer_ra=0x406f8a <__gnat_Unwind_RaiseException(_Unwind_Exception*)+17>)
    at ../../../gcc-10.3.0/libgcc/unwind-dw2.c:1593
#2  0x01e2ba3d in _Unwind_RaiseException (exc=0x132d8a90)
    at ../../../gcc-10.3.0/libgcc/unwind.inc:93
#3  0x00406f8a in __gnat_Unwind_RaiseException (e=e@entry=0x132d8a90)
    at ../../gcc-11.2.0/gcc/ada/raise-gcc.c:1391
#4  0x0048e3b3 in ada.exceptions.exception_propagation.propagate_gcc_exception
    (gcc_exception=0x132d8a90)
    at ../../gcc-11.2.0/gcc/ada/libgnat/a-exexpr.adb:597
#5  0x0048e402 in ada.exceptions.exception_propagation.propagate_exception (
    excep=...) at ../../gcc-11.2.0/gcc/ada/libgnat/a-exexpr.adb:628
#6  0x0048e880 in ada.exceptions.complete_and_propagate_occurrence (
    x=x@entry=0x132d8ac0) at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:924
#7  0x0048e8b3 in <__gnat_raise_exception> (
    e=0x207a990 <sem_prag.analyze_pragma.pragma_exit>, message=...)
    at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:960
#8  0x007e816c in sem_prag.analyze_pragma.check_valid_library_unit_pragma ()
    at ../../gcc-11.2.0/gcc/ada/sem_prag.adb:6605
#9  0x007deae3 in sem_prag.analyze_pragma (n=33616)
    at ../../gcc-11.2.0/gcc/ada/sem_prag.adb:21911
#10 0x006a1445 in sem.analyze (n=33616)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:465
#11 0x007186da in sem_ch3.analyze_declarations (l=-99996169)
    at ../../gcc-11.2.0/gcc/ada/sem_ch3.adb:2655
#12 0x00770b7d in sem_ch7.analyze_package_specification (n=33606)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:1582
#13 0x006a1425 in sem.analyze (n=33606)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:459
#14 0x00770856 in sem_ch7.analyze_package_declaration (n=33729)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:1210
#15 0x006a13f5 in sem.analyze (n=33729)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:450
#16 0x006deab8 in sem_ch12.analyze_package_instantiation (n=33272)
    at ../../gcc-11.2.0/gcc/ada/sem_ch12.adb:4773
#17 0x006a1405 in sem.analyze (n=33272)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:453
#18 0x007186da in sem_ch3.analyze_declarations (l=-99996197)
    at ../../gcc-11.2.0/gcc/ada/sem_ch3.adb:2655
#19 0x00770b7d in sem_ch7.analyze_package_specification (n=33260)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:1582
#20 0x006a1425 in sem.analyze (n=33260)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:459
#21 0x00770856 in sem_ch7.analyze_package_declaration (n=33354)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:1210
#22 0x006a13f5 in sem.analyze (n=33354)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:450
#23 0x006cbb45 in sem_ch10.analyze_compilation_unit (n=33243)
    at ../../gcc-11.2.0/gcc/ada/sem_ch10.adb:913
#24 0x006a0e55 in sem.analyze (n=33243)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:180
#25 0x006a24b9 in sem.semantics.do_analyze ()
    at ../../gcc-11.2.0/gcc/ada/sem.adb:1421
#26 0x006a292d in sem.semantics (comp_unit=33243)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:1615
#27 0x00687752 in rtsfind.load_rtu (u_id=system_img_int, id=re_image_integer,
    use_setting=false) at ../../gcc-11.2.0/gcc/ada/rtsfind.adb:1156
#28 0x0068838a in rtsfind.rte (e=re_image_integer)
    at ../../gcc-11.2.0/gcc/ada/rtsfind.adb:1506
#29 0x005bd859 in exp_imgv.expand_image_attribute (n=6229)
    at ../../gcc-11.2.0/gcc/ada/exp_imgv.adb:750
#30 0x0050e140 in exp_attr.expand_n_attribute_reference (n=6229)
    at ../../gcc-11.2.0/gcc/ada/exp_attr.adb:3931
#31 0x005ed275 in expander.expand (n=6229)
    at ../../gcc-11.2.0/gcc/ada/expander.adb:205
#32 0x00802c25 in sem_res.resolve (n=6229, typ=128)
    at ../../gcc-11.2.0/gcc/ada/sem_res.adb:3399
#33 0x0071b2f5 in sem_ch3.analyze_object_declaration (n=6226)
    at ../../gcc-11.2.0/gcc/ada/sem_ch3.adb:4302
#34 0x006a11e5 in sem.analyze (n=6226) at ../../gcc-11.2.0/gcc/ada/sem.adb:351
#35 0x007186da in sem_ch3.analyze_declarations (l=-99999533)
    at ../../gcc-11.2.0/gcc/ada/sem_ch3.adb:2655
#36 0x0075e2ca in sem_ch6.analyze_subprogram_body_helper (n=6217)
    at ../../gcc-11.2.0/gcc/ada/sem_ch6.adb:5156
#37 0x0075c568 in sem_ch6.analyze_subprogram_body (n=6217)
    at ../../gcc-11.2.0/gcc/ada/sem_ch6.adb:2818
#38 0x006a15fd in sem.analyze (n=6217) at ../../gcc-11.2.0/gcc/ada/sem.adb:547
#39 0x007186da in sem_ch3.analyze_declarations (l=-99999978)
    at ../../gcc-11.2.0/gcc/ada/sem_ch3.adb:2655
#40 0x0076f8db in sem_ch7.analyze_package_body_helper (n=2413)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:954
#41 0x0076ee0a in sem_ch7.analyze_package_body (n=2413)
    at ../../gcc-11.2.0/gcc/ada/sem_ch7.adb:180
#42 0x006a13d5 in sem.analyze (n=2413) at ../../gcc-11.2.0/gcc/ada/sem.adb:444
#43 0x006cbb45 in sem_ch10.analyze_compilation_unit (n=2335)
    at ../../gcc-11.2.0/gcc/ada/sem_ch10.adb:913
#44 0x006a0e55 in sem.analyze (n=2335) at ../../gcc-11.2.0/gcc/ada/sem.adb:180
#45 0x006a24b9 in sem.semantics.do_analyze ()
    at ../../gcc-11.2.0/gcc/ada/sem.adb:1421
#46 0x006a292d in sem.semantics (comp_unit=2335)
    at ../../gcc-11.2.0/gcc/ada/sem.adb:1615
#47 0x00604842 in frontend () at ../../gcc-11.2.0/gcc/ada/frontend.adb:422
#48 0x0089b6d9 in gnat1drv () at ../../gcc-11.2.0/gcc/ada/gnat1drv.adb:1237
#49 0x004243d4 in gnat_parse_file ()
    at ../../gcc-11.2.0/gcc/ada/gcc-interface/misc.c:118
#50 0x00d994a8 in compile_file () at ../../gcc-11.2.0/gcc/toplev.c:457
#51 0x00d9c382 in do_compile () at ../../gcc-11.2.0/gcc/toplev.c:2201
#52 0x00d9c66f in toplev::main (this=0x1070febe, argc=46, argv=0x12e11e40)
    at ../../gcc-11.2.0/gcc/toplev.c:2340
#53 0x01b7a6ab in main (argc=46, argv=0x12e11e40)
    at ../../gcc-11.2.0/gcc/main.c:39
(gdb)

Thanks for the log, exception propagation crept in again in the bootstrap causing the same kind of issues as last time, investigating how to get rid of exception propagation when compiling a-except.adb

> Thanks for the log, exception propagation crept in again in the bootstrap
> causing the same kind of issues as last time, investigating how to get rid
> of exception propagation when compiling a-except.adb

Are you referring to PR ada/80590?  Note that this was an exception propagation during the build of the runtime for a --disable-bootstrap build.

So we have the dreaded mix of 11.x Ada exception code and 10.x unwind code:

#0  0x773bb68b in msvcrt!abort () from C:\WINDOWS\SysWOW64\msvcrt.dll
#1  0x02074f7d in uw_init_context_1 (context=context@entry=0x1070c890,
    outer_cfa=outer_cfa@entry=0x1070ca70,
    outer_ra=0x406f8a <__gnat_Unwind_RaiseException(_Unwind_Exception*)+17>)
    at ../../../gcc-10.3.0/libgcc/unwind-dw2.c:1593
#2  0x01e2ba3d in _Unwind_RaiseException (exc=0x132d8a90)
    at ../../../gcc-10.3.0/libgcc/unwind.inc:93
#3  0x00406f8a in __gnat_Unwind_RaiseException (e=e@entry=0x132d8a90)
    at ../../gcc-11.2.0/gcc/ada/raise-gcc.c:1391

On the one hand, this should no longer exist on the mainline but, on the other hand, this has never been problematic for AdaCore's internal builds.

Right, PR ada/80590.
And yes, the previous PR was more of a special case while this PR is in the middle of the bootstrap path (triggers as part of compiling a-except.adb).

> And yes, the previous PR was more of a special case while this PR is in the
> middle of the bootstrap path (triggers as part of compiling a-except.adb).

Right.  As a last resort, I'm OK to try backporting the improved bootstrap process present on the mainline onto this 11 branch.

(In reply to Eric Botcazou from comment #60)
> > And yes, the previous PR was more of a special case while this PR is in the
> > middle of the bootstrap path (triggers as part of compiling a-except.adb).
> 
> Right.  As a last resort, I'm OK to try backporting the improved bootstrap
> process present on the mainline onto this 11 branch.

No need to, there are actually several reasons to not rely on exception propagation during bootstrap, so let's restore this invariant instead, I'm testing a change to that effect.

> No need to, there are actually several reasons to not rely on exception
> propagation during bootstrap, so let's restore this invariant instead, I'm
> testing a change to that effect.

Fair enough.  In any case, the symptoms are again consistent with a lack of registration of unwind tables, this time for libgcc, so this might be the same underlying issue as the grep-induced mess for GCC 10.  My hunch would point to a  constructor section merging issue in the linker, maybe related to the GCC configure check for HAVE_LD_RO_RW_SECTION_MIXING, which should fail for MinGW and may incorrectly succeed when things go wrong.

(In reply to Eric Botcazou from comment #62)
> > No need to, there are actually several reasons to not rely on exception
> > propagation during bootstrap, so let's restore this invariant instead, I'm
> > testing a change to that effect.
> 
> Fair enough.  In any case, the symptoms are again consistent with a lack of
> registration of unwind tables, this time for libgcc, so this might be the
> same underlying issue as the grep-induced mess for GCC 10.  My hunch would
> point to a  constructor section merging issue in the linker, maybe related
> to the GCC configure check for HAVE_LD_RO_RW_SECTION_MIXING, which should
> fail for MinGW and may incorrectly succeed when things go wrong.

Right, that's most likely the underlying issue and indeed ensuring we don't use exception propagation during the bootstrap is just a way to hide/avoid this underlying mismatch.

Searching for HAVE_LD_RO_RW_SECTION_MIXING in the build directory used for extracting the previous gdb backtraces shows this:

gcc/auto-host.h:1684:11:/* #undef HAVE_LD_RO_RW_SECTION_MIXING */

> Searching for HAVE_LD_RO_RW_SECTION_MIXING in the build directory used for
> extracting the previous gdb backtraces shows this:
> 
> gcc/auto-host.h:1684:11:/* #undef HAVE_LD_RO_RW_SECTION_MIXING */

Thanks.  Do you still have this line:

00000000 r .eh_frame

for crtend.o of the GCC 10 compiler after the grep mess was resolved?  Do you have the same line for the crtend.o of the GCC 11 compiler?

(In reply to Eric Botcazou from comment #65)
> Thanks.  Do you still have this line:
> 
> 00000000 r .eh_frame
> 
> for crtend.o of the GCC 10 compiler after the grep mess was resolved?  Do
> you have the same line for the crtend.o of the GCC 11 compiler?

The problem with grep didn't affect my gcc 10 install because it was built with grep 3.0, so crtend.o didn't change. Here it is again for completeness:

$ for f in `find /mingw32 -name crtend.o` ; do echo $f && nm $f ; done          /mingw32/lib/gcc/i686-w64-mingw32/10.3.0/crtend.o
00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 r .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 t .text.startup
00000000 r ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor


Now, these are the crtend.o created in the gcc 11.2 build directory before it failed at a-except.o (this is also with grep 3.0, while in comment#29 was with the botched grep 3.6, but I see no differences):

$ for f in `find /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32 -name crtend.o` ; do echo $f && nm $f ; done
/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-gcc/crtend.o
00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 r .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 r ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor
/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-i686-w64-mingw32/libgcc/crtend.o
00000000 b .bss
00000000 d .ctors.65535
00000000 d .data
00000000 r .eh_frame
00000000 r .rdata$zzz
00000000 t .text
00000000 r ___FRAME_END__
         U ___gcc_register_frame
00000000 t _register_frame_ctor


Note that, as before, .text.startup is present in gcc-10 but missing in gcc-11 crtend.o.

> Note that, as before, .text.startup is present in gcc-10 but missing in
> gcc-11 crtend.o.

That's expected if you compile with -Og or -O1, i.e. it requires -O2 or above.

The master branch has been updated by Eric Botcazou <ebotcazou@gcc.gnu.org>:

https://gcc.gnu.org/g:8fe93cc664ded8cc1952da28b23f3fc68504a73e

commit r12-4530-g8fe93cc664ded8cc1952da28b23f3fc68504a73e
Author: Arnaud Charlet <charlet@adacore.com>
Date:   Wed Oct 20 10:23:40 2021 +0200

    Avoid exception propagation during bootstrap
    
    This addresses PR ada/100486, which is the bootstrap failure of GCC 11 for
    32-bit Windows in the MSYS setup.  The PR shows that we cannot rely on
    exception propagation being operational during the bootstrap, at least on
    the 11 branch, so fix this by removing the problematic raise statement.
    
    gcc/ada/
            PR ada/100486
            * sem_prag.adb (Check_Valid_Library_Unit_Pragma): Do not raise an
            exception as part of the bootstrap.

The releases/gcc-11 branch has been updated by Eric Botcazou <ebotcazou@gcc.gnu.org>:

https://gcc.gnu.org/g:40b209e340b610248f9b1eec082f6b1ff734a2d0

commit r11-9177-g40b209e340b610248f9b1eec082f6b1ff734a2d0
Author: Arnaud Charlet <charlet@adacore.com>
Date:   Wed Oct 20 10:23:40 2021 +0200

    Avoid exception propagation during bootstrap
    
    This addresses PR ada/100486, which is the bootstrap failure of GCC 11 for
    32-bit Windows in the MSYS setup.  The PR shows that we cannot rely on
    exception propagation being operational during the bootstrap, at least on
    the 11 branch, so fix this by removing the problematic raise statement.
    
    gcc/ada/
            PR ada/100486
            * sem_prag.adb (Check_Valid_Library_Unit_Pragma): Do not raise an
            exception as part of the bootstrap.

Tentatively fixed, reopen if not.

(In reply to Eric Botcazou from comment #70)
> Tentatively fixed, reopen if not.

The bootstrap works.

Thank you.

Works nicely now. Thanks everyone!

In a similar bug 105507 we figured out that the MSYS2 build was broken because it was linking libgcc both statically and dynamically via dependencies, and that breaks exceptions with dwarf-2.

So in theory the above patch could be reverted. I can try building with it being reverted to confirm, if wanted.

The patch is desirable even outside of this PR, so we'll keep it. And as shown by PR105507, we have other exception propagation that crept in unintentionally, so I'll also have a look at these when I get a chance.