Exception handling totally broken on i686

[oscarfv]

Trying to attack #4543.

Starting with this simple case, where gcc is 8.2.1/i686 (sans ada/obj-c/fortran):

#include <stdio.h>

void foo() {
  throw 0;
}

int main() {
  try {
    foo();
  }
  catch(...) {
    puts("catched\n");
  }
}

$ g++ -g -O0 throw.cpp -o t.exe

oscar@win8-64-vm MINGW32 /d/dev/exp
$ ./t.exe

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
terminate called after throwing an instance of 'int'
terminate called recursively

oscar@win8-64-vm MINGW32 /d/dev/exp
$ gdb t.exe
GNU gdb (GDB) 8.2
Copyright (C) 2018 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:
<http://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 t.exe...done.
(gdb) catch throw
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
terminate called recursively

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

However, if the program is compiled with gcc 7.3.0-2, the program and gdb works fine.

Thus, the debugger is of no help. Bisection is not an option either, when a gcc build takes 1 hour.

My suspicion is a codegen bug on throw or catch.

Any ideas about how to chase this bug?

[oscarfv]

Building gcc 7.3.0-2 (after git checkout 0145502) yields a compiler that creates executables with the same problem. Now I'll revert to some old mingw-runtime to check if it changes anything. Already checked that binutils is not the culprit, because building gcc (8.2) with version 2.28 solves nothing.

[oscarfv]

Building after reverting the runtime with

 pacman -U /var/cache/pacman/pkg/mingw-w64-i686-crt-git-6.0.0.5225.fb06a4bf-1-any.pkg.tar.xz /var/cache/pacman/pkg/mingw-w64-i686-headers-git-6.0.0.5225.fb06a4bf-1-any.pkg.tar.xz

produces a faulty compiler. More precise, the problem is with gcc-libs. Using the mingw-w64-i686-gcc-libs package from the official repo works fine, even with the new compiler.

Trying to build gcc 7.3.0 with a MinGW-w64 CRT 5.0.0 fails with

checking for the correct version of the gmp/mpfr/mpc libraries... no
configure: error: Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+.
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
their locations.

Of course, those libraries are listed on makedepends and installed.

I think that something changed on the CRT that "infects" the gcc-libs breaking exception support. Probably is the cause of the Ada breakage too.

Next thing is to find (or build) a CRT prior to the problematic change and that does not break the gcc build with bogus errors about missing GMP/MPFR/MPC.

[oscarfv]

Tried

pacman -U /var/cache/pacman/pkg/mingw-w64-i686-crt-git-6.0.0.5066.61efe559-1-any.pkg.tar.xz /var/cache/pacman/pkg/mingw-w64-i686-headers-git-6.0.0.5066.61efe559-1-any.pkg.tar.xz

The resulting gcc has the same problem.

That version of the mingw-w64 runtime was packaged on December 2017, while gcc 7.3.0-2 was packages on April 2018.

[oscarfv]

Downgrading binutils and winpthread to versions published before the "good" gcc 7.3.0-2 was released does not produce a good gcc-libs package. The simple test case on the original message of this PR, compiled with the good 7.3.0-2 packages, fails as soon as the just-built 7.3.0-2 gcc-libs is installed.

I can't see how the rest of the makedepends could cause exceptions to fail.

Too bad that we have no reproducible builds nor something like Nix.

[mati865]

Trying to build gcc 7.3.0 with a MinGW-w64 CRT 5.0.0 fails with

It probably means building gmp code failed, you might find something useful in config.log.

[Alexpux]

@oscarfv @mati865 probably something goes wrong when GCC configured, that is why "bad" libs are produced

[oscarfv]

Following a suggestion from @mati865 , downgraded grep to 3.0-1 and now the resulting gcc 8.2 does not show the problem with exceptions.

@mati865 : why you suggested downgrading grep?

[mati865]

Because of this change:

The following changes affect only MS-Windows platforms. First, the
--binary (-U) option now governs whether binary I/O is used, instead
of a heuristic that was sometimes incorrect. Second, the
--unix-byte-offsets (-u) option now has no effect on MS-Windows too.

[Alexpux]

Grep will be downgraded in repo soon