MINGW-packages 🚀 - GCC languages

IMO this is not the appropriate forum to ask this question if you want a representative answer from the MSYS2 user base. I suppose that the mailing list has a wider audience.

A different approach is to drop those languages on the next release and wait for the rage :-)

oscarfv on 31 Jul 2018

👍1

@oscarfv once Ada will be dropped it is not easy to return it as you need Ada to build Ada

Alexpux on 31 Jul 2018

👍1

I think it's okay to keep building GCC with Objective-C and Ada support. A lot of software is written in either of these languages, not just C, C++, or Fortran. If these languages were removed from GCC, we would be unable to build such software and thus the toolchain would become more limited.

Adsun701 on 31 Jul 2018

👍2

The problem is it's not currently possible to build them (at least Ada) at present so to make progress that needs fixed or we ditch those languages.

mingwandroid on 31 Jul 2018

@mingwandroid I understand that due to patching efforts it takes a while to update a compiler with a certain language. A frequency of a language being used in software development, however, does not justify removing it from the compiler.

Adsun701 on 31 Jul 2018

👍2

That's not the issue and I'd prefer not to remove them (despite never personally using either compiler nor intending to ever).

The issue is that someone needs to fix this (I do not have time), or Alexey drops them or we stagnate compiler wise.

If someone cares enough they'll have to step up and do the work IMHO.

mingwandroid on 31 Jul 2018

@Alexpux : so let's suppose you drop those languages in 8.2 and then someone comes with a fix. Is it reasonable to expect that future gcc versions on the next two years or so will be buildable with 7.3?

Your original question, as it stands right now, is to either don't provide 8.x with Ada+ObjC or don't provide 8.x at all. IMHO it is not beneficial for the community to block access to 8.2 for indefinite time. You can release 8.2 without those languages and Ada+ObjC users can still use 7.3 until the problem is fixed.

oscarfv on 31 Jul 2018

@oscarfv I’m upload full GCC 8.2.0 suite for 64 bit, 32 will stay on 7.3 while it not fixed. If I drop Ada and upload GCC without it then I will not be able to build Ada later as it require Ada for building and I will need use some other toolchain that have Ada. So right now I decide to stay on 7.3 for 32 bit as long as it will not be fixed.

Alexpux on 31 Jul 2018

@Alexpux I don't understand how that helps, but as long as is possible to build i686 GCC 8.2 from the PKBUILD those of us who are eagerly waiting for it (because its improved C++17 support) have some hope.

oscarfv on 31 Jul 2018

Just a side note: I built aomenc in MABS, and a doom9 video forum user reported that the 64-bit build (compiled with GCC 8.2.0 now) crashes, in contrast to an earlier build compiled with GCC 7.3.0. This might be a hint that there are compiler issues. But there are still other possible reasons... to be investigated.

P.S.:
aomedia issue 2055 – Segmentation fault when encoding (introduced by "Remove code about dev speed features")
Summary: So it looks like -ftree-slp-vectorize is the culprit here

LigH-de on 10 Aug 2018

GCC developers have been notified of the vectorization producing unaligned memory access.

LigH-de on 15 Aug 2018

Current snapshot GCC-8-20180928 still not buildable for 32 bit:
````
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc g-exptty.adb -o g-exptty.o
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc g-flocon.ads -o g-flocon.o
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc g-forstr.adb -o g-forstr.o
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc g-heasor.adb -o g-heasor.o
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc g-hesora.adb -o g-hesora.o
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc g-hesorg.adb -o g-hesorg.o
configure: updating cache ./config.cache
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc g-htable.adb -o g-htable.o

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

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
xgcc.exe: internal compiler error: Aborted signal terminated program gnat1
Please submit a full bug report,
with preprocessed source if appropriate.
See https://sourceforge.net/projects/msys2 for instructions.
make[6]: * [../gcc-interface/Makefile:296: g-exptty.o] Error 4
make[6]: * Waiting for unfinished jobs....
````

Alexpux on 30 Sep 2018

Is there a bug report for the Ada problem on GCC's bugzilla? One Ada maintainer on the GCC mailing list asked this.

oscarfv on 18 Oct 2018

@oscarfv I dont remember

Alexpux on 18 Oct 2018

I suspect that the problem with Ada is related to the problem with exceptions of 8.x on x86. A few weeks ago I built gcc without Ada and C++ programs compiled with it crashes whenever an exception is thrown/catched. AFAIK Ada uses the same machinery as C++ for exceptions.

Possibly related to #4543 as well.

oscarfv on 24 Oct 2018

@oscarfv I'm thinking more and more that problem maybe in mingw-w64 runtime itself. I think about this because even if I rebuild GCC 7.3.0 it starting to crash applications. See https://github.com/Alexpux/MINGW-packages/issues/4543

Alexpux on 25 Oct 2018

Clang++ also crashes here when exceptions are involved on i686, while on x86_64 works fine.

I also wonder why mingw-builds does not offer a gcc 8.2 binary package and still are at 8.1. Made a web search but found no relevant discussion of the matter.

oscarfv on 25 Oct 2018

Hi @mstorsjo, do you have any idea about exceptions issue mentioned in last three comments here? (https://github.com/Alexpux/MINGW-packages/issues/4125#issuecomment-432829422, https://github.com/Alexpux/MINGW-packages/issues/4125#issuecomment-432915900, https://github.com/Alexpux/MINGW-packages/issues/4125#issuecomment-433038130)

mati865 on 25 Oct 2018

Hi @mstorsjo, do you have any idea about exceptions issue mentioned in last three comments here? (#4125 (comment), #4125 (comment), #4125 (comment))

I don't know of any reason for crashes with that with GCC - but I guess it would be worthwhile to check rebuilding gcc, libgcc and everything else with SJLJ for exceptions - that would at least help narrow down the issue a bit.

With Clang, I've seen issues with DWARF exceptions on i686 (where the exceptions aren't caught properly), this is https://github.com/mstorsjo/llvm-mingw/issues/8. For that particular issue, I thought the issue is some mismatch between the generated code, the unwind info and how libunwind tries to walk the call stack. That particular issue, I think, is pretty specific to the fact that clang normally only uses a 4 byte aligned stack on i686 on windows, while GCC assumes a 16 byte aligned stack. So far, I have guessed that that particular issue was a libunwind bug, but if people see similar issues with libgcc, the issue might lie on the clang side.

Also, if Clang built code crashes, but the root of the issue is within libstdc++ which has been built with GCC, it might just be the same GCC issue showing up, regardless of what compiler builds the outermost layer of the executable.

mstorsjo on 25 Oct 2018

👍2

I just updated my MSYS2 installation and was surprised that I had to uninstall the Ada compiler to do so and even more that Ada is no longer available in MSYS2 at all. However, having access to an Ada compiler is important for me, as it is needed to build GHDL. GHDL is entirely implemented in Ada and the most complete open-source VHDL simulator available. It is an important EDA tool to simulate digital systems.

maehne on 9 Jun 2019

@maehne unfortunately nobody here is able to fix Ada. Upstream haven't fixed it for over a year so there is no choice for MSYS2.

mati865 on 9 Jun 2019

It was a little surprising to see x86_64 Ada removed as well when only the i686 fails to build.

@maehne : your only options right now is to either not upgrade or build the x86_64 version of gcc after re-enabling Ada. Fortunately Alexpux introduced a toggle on gcc's PKGBUILD that makes trivial to re-enable Ada. The process is very simple, take a look at https://github.com/msys2/msys2/wiki/Creating-Packages and ask if necessary. In short:

Download the files contained on the directory mingw-w64-gcc of this repository to a new empty local directory (avoid blank spaces on the directory's name and on its parent's).
Open a MSYS2 shell (not a MINGW64 or MINGW32 shell) and cd to that directory.
Edit PKGBUILD and change _enable_ada=no to _enable_ada=yes.
Execute the command MINGW_INSTALLS=mingw64 makepkg-mingw --skippgpcheck -s.

The process will ask for permission to install the required build dependencies and proceed with the build. At the end you will have the binary packages on the same directory. That's all.

oscarfv on 9 Jun 2019

Thanks, @Alexpux and @oscarfv for your quick reply! I agree with @oscarfv that it is a pity that the x86_64 version of the Ada compiler has been removed when only the i686 variant was affected. Unfortunately, I am not able anymore to build the mingw-w64-gcc-ada package myself as this requires a working Ada compiler for bootstrapping, which I unfortunately uninstalled to fix the upgrade errors reported by pacman. Is there some way to downgrade to an older version of the package, which is still available as a binary package?

maehne on 9 Jun 2019

@maehne : on http://repo.msys2.org there is an archive of released binary packages. You need to download mingw-w64-x86_64-gcc*<version>.xz packages and install them with pacman -U <package-file-name> <package-file-name>... or simply put them on an empty directory and pacman -U *.

If gcc 8.3 is good enough for you, there is no need to build 9.1. In any case, you should edit /etc/pacman.conf and add

IgnorePkg   = mingw-x86_64-gcc mingw-x86_64-gcc-ada <etc>

Otherwise pacman will try to upgrade those packages on the next -Suy invocation.

oscarfv on 9 Jun 2019

Please readd ObjC: #5538

Midar on 16 Jun 2019

As far as Ada is concerned, I have hopefully worked around the blocking issue under https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80590
The details are that GCC 8 switched to zero cost exception handling instead of sjlj for Ada, thus requiring a full bootstrap of the compiler to support exception handling properly (including in the compiler itself).
So in other words, if you do a bootstrap (remove the --disable-bootstrap configure switch) then the Ada issue will disappear. The changes I've made in the GCC sources (branches 8, 9 and master) should still allow you to build an Ada compiler without bootstrapping, but this is walking on thin ice, and I'd strongly recommend that you either bootstrap rapidly, or at least use this more recent (e.g. GCC 8.x) compiler to perform newer builds (e.g. GCC 9 and 10).
Let me know how it goes.

ArnaudCharlet on 17 Jun 2019

🎉1

@ArnaudCharlet we always bootstrap GCC - https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD#L179

Alexpux on 17 Jun 2019

Interesting then since this doesn't correspond to what was reported under https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80590, so not quite the same issue.
Which base compiler are you using for the bootstrap by the way?
In any case, let me know how a build with Ada enabled goes with the latest GCC sources, the compilation of g-exptty.adb should at least pass now. But then there might still be remaining issues with exception handling, in particular if C++ is impacted too, so probably more on the pure mingw64 side.

ArnaudCharlet on 17 Jun 2019

@ArnaudCharlet as you can see original issue is dated a year ago when we switch from GCC 7.2 or 7.3 to 8.0. Since this time we not be able to build Ada anymore for 32 bit

Alexpux on 17 Jun 2019

I understand that. Sorry if my questions sound stupid/simple to you since you are familiar with how msys2 is built and I'm not, hence my questions. So what version of GCC are you using for bootstrapping GCC 8.x (and same question for GCC 9x)? Is that the previous version 7.2.x or an older version?

Also if exception support is broken for C++ then you might want to use "--enable-sjlj-exceptions" instead of "--disable-sjlj-exceptions --with-dwarf2" (or remove explicitly these last two switches) when configuring, although loosing zcx exceptions would be too bad if this can be avoided.

Anyway, let me know if you manage to reenable Ada in GCC 8 or 9 builds with latest FSF GCC sources, that'd be great.

ArnaudCharlet on 17 Jun 2019

@ArnaudCharlet yes we bootstrap GCC using previous version. So when we switch to 8.x we use 7.x toolchain.

We cant just switch from dwarf to sjlj exceptions really.

Alexpux on 17 Jun 2019

@ArnaudCharlet patch from PR80590 not help much. Build fail some later:
````
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc a-cbhase.adb -o a-cbhase.o
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc a-cbmutr.adb -o a-cbmutr.o
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc a-cborma.adb -o a-cborma.o
checking for __atomic_fetch_add for size 1... /mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc a-cborse.adb -o a-cborse.o
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc a-cbprqu.adb -o a-cbprqu.o
yes
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc a-cbsyqu.adb -o a-cbsyqu.o
yes
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc a-cdlili.adb -o a-cdlili.o
checking whether -pthread is supported... /mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc a-cfdlli.adb -o a-cfdlli.o
no
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc a-cfhama.adb -o a-cfhama.o
/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/./gcc/xgcc -B/mingw_repo/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 -c -g -O2 -W -Wall -gnatpg -nostdinc a-cfhase.adb -o a-cfhase.o
checking for __atomic_fetch_add for size 2... no
yes
checking for strtoull...
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
xgcc.exe: internal compiler error: Aborted signal terminated program gnat1
Please submit a full bug report,
with preprocessed source if appropriate.
See https://sourceforge.net/projects/msys2 for instructions.
make[6]: * [../gcc-interface/Makefile:299: a-cfdlli.o] Error 4
make[6]: * Waiting for unfinished jobs....

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

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
xgcc.exe: internal compiler error: Aborted signal terminated program gnat1
Please submit a full bug report,
with preprocessed source if appropriate.
See https://sourceforge.net/projects/msys2 for instructions.
make[6]: * [../gcc-interface/Makefile:299: a-cfhama.o] Error 4

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

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
xgcc.exe: internal compiler error: Aborted signal terminated program gnat1
Please submit a full bug report,
with preprocessed source if appropriate.
See https://sourceforge.net/projects/msys2 for instructions.
make[6]: * [../gcc-interface/Makefile:299: a-cfhase.o] Error 4
checking whether fflush_unlocked is declared... configure: updating cache ./config.cache
make[6]: Leaving directory '/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc/ada/rts'
make[5]: [gcc-interface/Makefile:614: gnatlib] Error 2
make[5]: Leaving directory '/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc/ada'
make[4]: [gcc-interface/Makefile:735: gnatlib-shared-win32] Error 2
make[4]: Leaving directory '/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc/ada'
make[3]: [gcc-interface/Makefile:795: gnatlib-shared] Error 2
make[3]: Leaving directory '/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc/ada'
make[2]: [Makefile:104: gnatlib-shared] Error 2
make[2]: Leaving directory '/mingw_repo/mingw-w64-gcc/src/build-i686-w64-mingw32/i686-w64-mingw32/libada'
make[1]: [Makefile:20924: all-target-libada] Error 2
make[1]: ** Waiting for unfinished jobs....
````

Alexpux on 17 Jun 2019

Too bad. So this confirms that the issue is really that exception handling on i686 is badly broken. Isn't that the same issue as reported for C++ in e.g. #4728 ? a-cfdlli.o basically requires exception propagation to an empty exception handler which is very basic exception propagation. So I suspect a similar misconfiguration as happened for C++ although I guess you now have a proper build for C++? Also, would it be possible to at least (re)enable Ada on x86_64 so that people wanting to use Ada are not completely blocked? Finally, can you try building GCC 8 with Ada using GCC 6 instead of GCC 7 on i686 (a shot in the dark really)?