gcc: Update to 11.1.0

[Astrum-polaris]

No description provided.

[lazka]

I'd like to wait a bit for a response to #8094 (comment) before updating gcc

[lazka]

Thanks. Looks good. We need to report this and debug this eventually :/ I've cherry picked the zstd/curl changes to master for now.

[dscho]

I've cherry picked the zstd/curl changes to master for now.

Heh, just when you did that, cURL v7.76.1 came out ;-) I'll open a separate PR for that.

[dscho]

I'll open a separate PR for that.

I just did, and for good measure I also opened a corresponding MSYS-packages PR.

[revelator]

btw you ask how to bootstrap ada with ucrt, you would probably need a cross compiler which initially might be easier to setup on linux.

[lazka]

no clear error message for mingw32, maybe https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 ?

[lazka]

I've cherry-picked your 10.3 changes to #8532

[Astrum-polaris]

I disabled ada in MINGW32, the build was successful but install failed because new gcc conflicts with old ada.

Do we want to disable ada in MINGW32 for now (and fix CI) or try reverting more commit or waiting for potential fixes?

[oscarfv]

We already released gcc without Ada support on the past, after trying hard to solve the blocking issue and then waiting a long time for a fix from upstream, which came shortly after the binaries were released when some users realized that Ada was missing and poked the Ada developers.

[lazka]

Filed a bug for the ada error: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486

[oscarfv]

Filed a bug for the ada error: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486

A gcc developer requested some extra info there. I provided what I know. The actual configure command is not shown on the CI build log.

[mati865]

Building with -j1 could be useful for finding the error/failing command but it will take long long time.

[oscarfv]

Building with -j1 could be useful for finding the error/failing command but it will take long long time.

The error is reported here:

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

and that file is compiled just a few lines above:

/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

IIUC this means that the compiler crashes, right?

[mati865]

This is make error meaning the compiler exited with status other than 0 or crashes. Usually there should be backtrace if it's a crash, unless unwinding is broken...

[jeremyd2019]

unless unwinding is broken...

Which it seems to frequently be. ☹️

[oscarfv]

Can we go ahead with this, please? Let's just release it without Ada on i686.

[revelator]

seems to be related to dwarf unwinding indeed i use sjlj in my personal build and it works there so :S

[oscarfv]

If 32-bit unwinding is broken (maybe it uses dwarf 5 now?) then it's bigger blocker than missing Ada.

Can anyone confirm that 32-bit unwinding is broken (outside of Ada)? And, if it is broken, is there a bug report on gcc's bugzilla?

[oscarfv]

Upstream is asking again for the configure line and mentions that a recent change on the gcc-11 branch could help.

[revelator]

odd that it only seems to affect the 32 bit build when using dwarf exceptions, i can build it no problem here using sjlj.

[revelator]

just tried building it with differing exception models, only dwarf builds fail :S seh and sjlj work just fine.
Did they change anything recently in the exception code for dwarf ? i tried making a diff against the previous libgcc but nothing appareant seems to have changed so im a bit miffed.

[mati865]

This is the change I was talking about:

For targets that produce DWARF debugging information GCC now defaults to DWARF version 5 (with the exception of VxWorks and Darwin/Mac OS X which default to version 2 and AIX which defaults to version 4). This can produce up to 25% more compact debug information compared to earlier versions.

[lazka]

Could this upstream fix be related gcc-mirror/gcc@8ce35e4 ?

edit: I'm going to backport that, it seems relevant -> #9085

[revelator]

lets cross fingers :)

[oscarfv]

Could this upstream fix be related gcc-mirror/gcc@8ce35e4 ?

edit: I'm going to backport that, it seems relevant -> #9085

I tried with that change backported. No dice, the build fails the same.

[revelator]

ya thinking abit about it this patch only seems to affect PECOFF so if it was broken it would affect all exception models i think ?.

[mati865]

ya thinking abit about it this patch only seems to affect PECOFF so if it was broken it would affect all exception models i think ?.

I don't think so, Clang uses different PIC mode between 32-bit and 64-bit Windows and I'd expect GCC to do the same.

[oscarfv]

So @lazka merge of the EH pointer fix worked?

This is great news, but now I wonder why mine failed.

[revelator]

ofc i ment in regards to the exception model :), on a hunch i tried bootstrapping gcc-11 with an older sjlj exception based model
and the result is that it builds Oo atleast this far as the bootstrap is not yet done (how far did the ci build go before it bonked out ?), im at stage2 and the gnat compiler itself has been built, so waiting to see if it fails on the ada runtime now.

if it does build the entire package that tells me that something might be up with our bootstrap compiler.

[lazka]

So @lazka merge of the EH pointer fix worked?

I backported it for 10.x. I assumed it might be helpful based on the upstream comment, but as always I have no clue in this area..:

AFAICS the failure occurs during stage #2 so the stage #1 compiler might be miscompiled by the base compiler

[revelator]

if i manage to build it would it be possible to use it in a ci build to bootstrap itself ? i can upload the packages once done.

[mati865]

It'd be worth to try building with #9085 first.

[revelator]

allready am ;)

[oscarfv]

So @lazka merge of the EH pointer fix worked?

I backported it for 10.x. I assumed it might be helpful based on the upstream comment, but as always I have no clue in this area..:

AFAICS the failure occurs during stage #2 so the stage #1 compiler might be miscompiled by the base compiler

Oh, I should look harder. But your motivation is interesting.

For the record, passing -dwarf-4 on CFLAGS/CXXFLAGS/BOOT_CFLAGS changes nothing.

[revelator]

stage 3 still going :D

[lazka]

oh, I tried to close/reopen to trigger CI again, but your branch is no longer there :(

[oscarfv]

@lazka : who is "you" in "your branch"?

Right now I'm building 10 with the PEH patch on C.I., then I'll download and install the packages and locally build 11 with the PEH patch.

Just in case you ( @lazka ) already uploaded the patched packages to C.I., (please confirm this) I'm re-running the 11+PEH patch on my C.I.

[revelator]

build successfully completed here, if the +PEH patch indeed does fix it for the ci build i wont go further, if not ill upload my build and you can try bootstrapping with that.

[lazka]

I've re-created this and rebased in #9088

@lazka : who is "you" in "your branch"?

I meant the author of this PR