[Bug bootstrap/98860] New: boostrap failure on MinGW-w64 windows 10

[Bug bootstrap/98860] New: boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

            Bug ID: 98860
           Summary: boostrap failure on MinGW-w64 windows 10
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

checking whether we are cross compiling... configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libatomic':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
.exe
checking whether we are cross compiling... make[1]: *** [Makefile:15606:
configure-target-libgomp] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:16174: configure-target-libatomic] Error 1
configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libssp':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libquadmath':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
make[1]: *** [Makefile:13329: configure-target-libssp] Error 1
make[1]: *** [Makefile:14375: configure-target-libquadmath] Error 1
make[1]: Leaving directory '/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32'
make: *** [Makefile:973: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

[Bug bootstrap/98860] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #1 from cqwrteur <unlvsur at live dot com> ---
The question is that why it says we are not cross-compiling? I am using the
same script I used before.
https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/PKGBUILD

It is so weird.


checking whether we are cross compiling... configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libgomp':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libatomic':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
.exe
checking whether we are cross compiling... make[1]: *** [Makefile:15606:
configure-target-libgomp] Error 1
make[1]: *** Waiting for unfinished jobs....
configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libssp':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
make[1]: *** [Makefile:16174: configure-target-libatomic] Error 1
configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libquadmath':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
make[1]: *** [Makefile:13329: configure-target-libssp] Error 1
make[1]: *** [Makefile:14375: configure-target-libquadmath] Error 1
make[1]: Leaving directory '/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32'
make: *** [Makefile:973: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

[Bug bootstrap/98860] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #2 from cqwrteur <unlvsur at live dot com> ---
I guess is because of this commit

https://github.com/gcc-mirror/gcc/commit/0411ae7f08e0f5a8b02ff313d26d27a0f6d1bb34

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0411ae7f08e0f5a8b02ff313d26d27a0f6d1bb34

[Bug bootstrap/98860] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #3 from cqwrteur <unlvsur at live dot com> ---
After revert to the previous commit. Compilation success

https://github.com/gcc-mirror/gcc/commit/bfab355012ca0f5219da8beb04f2fdaf757d34b7

I think it has to do with the script you changed, Jakub.

[Bug bootstrap/98860] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #4 from cqwrteur <unlvsur at live dot com> ---
Created attachment 50071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50071&action=edit
bootstrap failure picture

[Bug bootstrap/98860] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #5 from cqwrteur <unlvsur at live dot com> ---
I do not know whether it has to do with the CRLF issue because GCC on Linux
emits the same result as it does on MinGW-w64 or msys2.

conftextx.c

#ifdef __x86_64__
#ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
#error need -march=i486
#endif
#ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16
#error need -mcx16
#endif
#else
#ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
#error need -march=i686
#endif
#endif


MinGW32

unlvs@DESKTOP-DFHPDC1 MINGW32 ~/gcc_bug
$  gcc -E conftestx.c
# 1 "conftestx.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "conftestx.c"

unlvs@DESKTOP-DFHPDC1 MINGW32 ~/gcc_bug
$  gcc -E conftestx.c -march=i486
# 1 "conftestx.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "conftestx.c"
conftestx.c:10:2: error: #error need -march=i686
   10 | #error need -march=i686
      |  ^~~~~

MinGW64

unlvs@DESKTOP-DFHPDC1 MINGW64 ~/gcc_bug
$  gcc -E conftestx.c -m32
# 1 "conftestx.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "conftestx.c"

unlvs@DESKTOP-DFHPDC1 MINGW64 ~/gcc_bug
$  gcc -E conftestx.c -march=i486 -mtune=generic
# 1 "conftestx.c"
cc1.exe: error: CPU you selected does not support x86-64 instruction set

MSYS (which is x86_64 with CYGWIN)

unlvs@DESKTOP-DFHPDC1 MSYS ~/gcc_bug
$  gcc -E conftestx.c
# 1 "conftestx.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "conftestx.c"
conftestx.c:6:2: error: #error need -mcx16
    6 | #error need -mcx16
      |  ^~~~~

unlvs@DESKTOP-DFHPDC1 MSYS ~/gcc_bug
$  gcc -E conftestx.c -march=i486
# 1 "conftestx.c"
cc1: error: CPU you selected does not support x86-64 instruction set


The result on Linux:

cqwrteur@DESKTOP-DFHPDC1:/mnt/d/msys64/home/unlvs/gcc_bug$ gcc -E conftestx.c
# 0 "conftestx.c"
# 0 "<built-in>"
# 0 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "<command-line>" 2
# 1 "conftestx.c"
conftestx.c:6:2: error: #error need -mcx16
    6 | #error need -mcx16
      |  ^~~~~
cqwrteur@DESKTOP-DFHPDC1:/mnt/d/msys64/home/unlvs/gcc_bug$ gcc -E conftestx.c
-march=i486
# 0 "conftestx.c"
cc1: error: CPU you selected does not support x86-64 instruction set

[Bug bootstrap/98860] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #6 from cqwrteur <unlvsur at live dot com> ---
configure:4069: ./conftest.exe
/home/unlvs/mcf_build/src/gcc-git/libgomp/configure: line 4071: ./conftest.exe:
cannot execute binary file: Exec format error
configure:4073: $? = 126
configure:4080: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libgomp':
configure:4082: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|boostrap failure on         |[11 Regression] boostrap
                   |MinGW-w64 windows 10        |failure on MinGW-w64
                   |                            |windows 10
   Target Milestone|---                         |11.0

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #7 from cqwrteur <unlvsur at live dot com> ---
configure:3736: $? = 0
configure:3725: /home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include    -V >&5
xgcc.exe: error: unrecognized command-line option '-V'
xgcc.exe: fatal error: no input files
compilation terminated.
configure:3736: $? = 1
configure:3725: /home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include    -qversion >&5
xgcc.exe: error: unrecognized command-line option '-qversion'; did you mean
'--version'?
xgcc.exe: fatal error: no input files
compilation terminated.
configure:3736: $? = 1
configure:3756: checking whether the C compiler works
configure:3778: /home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include    -g -march=x86-64 -mtune=generic -O2
-pipe  -pipe
-Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high
conftest.c  >&5
configure:3782: $? = 0
configure:3830: result: yes
configure:3833: checking for C compiler default output file name
configure:3835: result: a.exe
configure:3841: checking for suffix of executables
configure:3848: /home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include    -o conftest.exe -g -march=x86-64
-mtune=generic -O2 -pipe  -pipe
-Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high
conftest.c  >&5
configure:3852: $? = 0
configure:3874: result: .exe
configure:3896: checking whether we are cross compiling
configure:3904: /home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/xgcc
-B/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/./gcc/
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include    -o conftest.exe -g -march=x86-64
-mtune=generic -O2 -pipe  -pipe
-Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high
conftest.c  >&5
configure:3908: $? = 0
configure:3915: ./conftest.exe
/home/unlvs/mcf_build/src/gcc-git/libatomic/configure: line 3917:
./conftest.exe: cannot execute binary file: Exec format error
configure:3919: $? = 126
configure:3926: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libatomic':
configure:3928: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #8 from cqwrteur <unlvsur at live dot com> ---
I tried to build this commit and it is successful.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0411ae7f08e0f5a8b02ff313d26d27a0f6d1bb34

which means it is another commit that breaks it

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #9 from cqwrteur <unlvsur at live dot com> ---
I tried to build this commit and it is successful.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0411ae7f08e0f5a8b02ff313d26d27a0f6d1bb34

which means it is another commit that breaks it.

Daily bump of 2021-01-18 fails
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4c9bcd5c81a010c06d177089176499926550625c

4c9bcd5c81a010c06d177089176499926550625c fails

However.

Daily bump of 2021-01-17 succ
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=59cf67d1cf77e9594e58fd2848ac94d505546546
succ

Which means it must be in the 6 patches that breaks

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jakub at redhat dot com            |

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In that range guess the only important change was the switch from -gdwarf-4 to
-gdwarf-5 by default.  So either a bug in your assembler or linker or something
else that doesn't like DWARF 5?

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #11 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jakub Jelinek from comment #10)
> In that range guess the only important change was the switch from -gdwarf-4
> to -gdwarf-5 by default.  So either a bug in your assembler or linker or
> something else that doesn't like DWARF 5?

MinGW-w64. I do not know. Maybe Binutils do not work with gdwarf-5 whatever?

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So you need to figure it out, most people here don't have any access to
Windows.
If mingw64 is using binutils, there were important DWARF 5 related bugs in in
binutils 2.35, but for the known ones we've added workarounds.  And much older
binutils don't really cope with DWARF 5 at all, but that on Linux certainly
doesn't result in inability to properly link programs.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #13 from cqwrteur <unlvsur at live dot com> ---
$ as --version
GNU assembler (GNU Binutils) 2.35.1
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #14 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jakub Jelinek from comment #12)
> So you need to figure it out, most people here don't have any access to
> Windows.
> If mingw64 is using binutils, there were important DWARF 5 related bugs in
> in binutils 2.35, but for the known ones we've added workarounds.  And much
> older binutils don't really cope with DWARF 5 at all, but that on Linux
> certainly doesn't result in inability to properly link programs.

https://github.com/msys2/MINGW-packages-dev/blob/master/mingw-w64-binutils-git/PKGBUILD

I think MSYS2 uses binutils of this.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #15 from Liu Hao <lh_mouse at 126 dot com> ---
Why did you add me in CC without asking for my acknowledgement?

If you had asked MSYS2 people, I am pretty sure you would have received more
constructive suggestions.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #16 from cqwrteur <unlvsur at live dot com> ---
I update to latest binutils and it still fails to build.
... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libgomp':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libatomic':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
.exe
checking whether we are cross compiling... checking whether we are cross
compiling... make[1]: *** [Makefile:15606: configure-target-libgomp] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:16174: configure-target-libatomic] Error 1
configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libssp':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
configure: error: in
`/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libquadmath':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
make[1]: *** [Makefile:13329: configure-target-libssp] Error 1
make[1]: *** [Makefile:14375: configure-target-libquadmath] Error 1
make[1]: Leaving directory '/home/unlvs/mcf_build/src/build-x86_64-w64-mingw32'
make: *** [Makefile:973: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jakub at gcc dot gnu.org           |

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Why do you keep CCing me on this?  I have nothing to do with Windows.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #18 from cqwrteur <unlvsur at live dot com> ---
I can confirm it is the commit that breaks the bootstrap on windows 10

https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/doc/invoke.texi;h=c290b6f4938f45e8d491d76d4940060e7b59be36;hp=3f30230b0c244245e23e29ea409277528cfc390c;hb=3804e937b0e252a7e42632fe6d9f898f1851a49c;hpb=59cf67d1cf77e9594e58fd2848ac94d505546546

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #19 from cqwrteur <unlvsur at live dot com> ---
After reverting the change, the compilation succeeds. However, this is a
temporary solution.

https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/9000-Revert-testsuite-Skip-DWARF-5-testcases-on-AIX.patch

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Liu Hao <lh_mouse at 126 dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|lh_mouse at 126 dot com            |

--- Comment #20 from Liu Hao <lh_mouse at 126 dot com> ---
0. You may ask about this issue on MSYS2 issue tracker [1].
1. Talk to the community (the 'people'), not an individual person.
2. Stop being noisy.


[1] https://github.com/msys2/MINGW-packages/issues

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brechtsanders at users dot sourcef
                   |                            |orge.net

--- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
*** Bug 98729 has been marked as a duplicate of this bug. ***

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[nix at esperi dot org.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Nix <nix at esperi dot org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nix at esperi dot org.uk

--- Comment #22 from Nix <nix at esperi dot org.uk> ---
I can confirm the same failure with an x86_64-pc-cygwin native build using a
GCC trunk current as of Jan 12 (a bit old, sorry) and, oh dear this might
explain it, binutils 2.35.1.

Trying again with trunk binutils now.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[nix at esperi dot org.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #23 from Nix <nix at esperi dot org.uk> ---
OK, that works: ignore me, in my case it was just using a too old binutils.
(The error message emitted is... unhelpful: exec format error, really?)

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[nix at esperi dot org.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #24 from Nix <nix at esperi dot org.uk> ---
... and ten seconds after I posted that it failed again. Looks like binutils
isn't quite ready for DWARF 5 on Windows yet :(

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Mikael Pettersson <mikpelinux at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #25 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Created attachment 50138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50138&action=edit
do not default to dwarf5 on Windows

I have the same problem with gcc-11 bootstrap failures due to Exec format
errors post stage 1 on Cygwin64, even with current binutils master. I don't
know if it's a bug in binutils or a limitation in Windows, but DWARF5 clearly
does not work there, so this patch disables it. Works for me on Cygwin64. Can
someone please test it on mingw-w64?

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #26 from cqwrteur <unlvsur at live dot com> ---
(In reply to Mikael Pettersson from comment #25)
> Created attachment 50138 [details]
> do not default to dwarf5 on Windows
> 
> I have the same problem with gcc-11 bootstrap failures due to Exec format
> errors post stage 1 on Cygwin64, even with current binutils master. I don't
> know if it's a bug in binutils or a limitation in Windows, but DWARF5
> clearly does not work there, so this patch disables it. Works for me on
> Cygwin64. Can someone please test it on mingw-w64?

What cygwin compilation script are you using? Can you show me. I want this.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[brechtsanders at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #27 from Brecht Sanders <brechtsanders at users dot sourceforge.net> ---
@Mikael Pettersson, should a similar patch be applied to
gcc/config/i386/mingw-w64.h to fix this same issue in MinGW-w64?

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #28 from Mikael Pettersson <mikpelinux at gmail dot com> ---
(In reply to Brecht Sanders from comment #27)
> @Mikael Pettersson, should a similar patch be applied to
> gcc/config/i386/mingw-w64.h to fix this same issue in MinGW-w64?

cygming.h is used for both mingw and cygwin, so no additional patch should be
needed.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #29 from cqwrteur <unlvsur at live dot com> ---
(In reply to Mikael Pettersson from comment #25)
> Created attachment 50138 [details]
> do not default to dwarf5 on Windows
> 
> I have the same problem with gcc-11 bootstrap failures due to Exec format
> errors post stage 1 on Cygwin64, even with current binutils master. I don't
> know if it's a bug in binutils or a limitation in Windows, but DWARF5
> clearly does not work there, so this patch disables it. Works for me on
> Cygwin64. Can someone please test it on mingw-w64?

test success. you can merge it to master now

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #30 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Patch has been posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564990.html

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #31 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Created attachment 50158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50158&action=edit
conftest.c (based configure's cross compilation test)

This runs Ok when compiled with "-O2 -g -gdwarf-4", but fails with Windows
error code 193 aka "Exec format error" when compiled with "-O2 -g -gdwarf-5".
The error is reproducible with a x86_64-w64-mingw32 cross (just transfer the
EXEs to Windows for execution).

Compiling with -S shows differences in several .debug sections.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> ---
FWIW Wine gives this error when trying to run binaries created by GCC trunk
(and binutils 2.34):

0104:err:process:exec_process L"Z:\\tmp\\a.exe" not supported on this system

Comparing the objdump -h output for a working a.exe (compiled with GCC 10.2)
and trunk, I see these extra sections for the trunk version:

  0 .debug_loclists 001e7053  0000000100000000  0000000100000000  00000480 
2**0
                  CONTENTS, READONLY, DEBUGGING
  1 .debug_rnglists 00058653  0000000100000000  0000000100000000  001e7680 
2**0
                  CONTENTS, READONLY, DEBUGGING

I'm not sure what else to compare.

Stripping all debug symbols from a.exe makes it usable with Wine.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-02-09
     Ever confirmed|0                           |1

--- Comment #33 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #32)
> FWIW Wine gives this error when trying to run binaries created by GCC trunk
> (and binutils 2.34):
> 
> 0104:err:process:exec_process L"Z:\\tmp\\a.exe" not supported on this system

i.e. there's no need to transfer anything to Windows for execution.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #34 from H.J. Lu <hjl.tools at gmail dot com> ---
This may be related to

https://sourceware.org/pipermail/binutils/2021-February/115395.html

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #35 from Richard Biener <rguenth at gcc dot gnu.org> ---
So this doesn't just affect bootstrap but any executable built by GCC 11 with
the new -gdwarf-5 default.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[ssbssa at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #36 from Hannes Domani <ssbssa at yahoo dot de> ---
Note: This is a binutils/ld bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=27268

And I've sent a patch there:
https://sourceware.org/pipermail/binutils/2021-February/115434.html

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |jyong at gcc dot gnu.org,
                   |                            |ktietz70 at googlemail dot com,
                   |                            |lh_mouse at 126 dot com

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Adding some CCs.  While a patch has been posted, we haven't seen an explanation
what exactly is going on and why.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #38 from Mikael Pettersson <mikpelinux at gmail dot com> ---
After updating binutils to ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0, including
the fix for BZ 27268, I was able to do a full bootstrap of current gcc head on
Cygwin64. https://sourceware.org/bugzilla/show_bug.cgi?id=27268 has more
detail.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, so what do we want to do on the gcc side?
Nothing, just tell users they need latest binutils?
Or try to add a configure check to detect broken binutils that doesn't handle
the DWARF5 new sections and if it detects broken binutils, in
ix86_option_override_internal if (TARGET_PECOFF && dwarf_version > 4) and
#ifdef the new macro about broken pecoff binutils set dwarf_version to 4
(if !global_options_set.x_dwarf_version silently, otherwise with a warning (but
perhaps just once per the whole TU))?
As I have no access to Windows, I'm afraid I can't easily write a configure
test myself, I can help with the i386-options.c change if needed, but can't
test anything.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #40 from jyong at gcc dot gnu.org ---
Personally I'm fine with gcc configure warning of a potentially broken binutils
dwarf5 handing when targeting mingw/cygwin with binutils 2.35.1 or earlier.

How do you even parse binutils versions? Of course, all bets are off if
build!=host.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
gcc/configure has e.g. $ld_vers_major and $ld_vers_minor and $ld_vers_patch.
But as the fix was March 1st, I think it is neither in 2.35.2 nor in 2.36.
I think a feature test would be better, try to assemble as short assembly as
possible with the new DWARF5 sections in it (with the actual code perhaps
replaced just by a nop), link it and look at it using objdump if the sections
are right or not?

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #42 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As a start, perhaps compiling
void
foo (void)
{
  int a = 1;
  asm ("nop");
  a = 2;
  asm ("nop");
  a = 3;
}
with -gdwarf-5 -O2 -dA to get the assembly.  But bet it can be reduced manually
somewhat, it would e.g. just drop the function altogether and in .debug_info
have just DW_TAG_compile_unit DIE with its attributes and drop
DW_TAG_subprogram etc., and only have DW_AT_ranges on it that points to minimal
.debug_rnglists.
Or keep the DW_TAG_subprogram in there but just say the ranges and nothing else
for it.
But if it needs to cover both 64-bit and 32-bit assembly for PE, either you
need two sets of assembly in the configure or tweak it by hand.
You can have a look e.g. at what the HAVE_AS_WORKING_DWARF_N_FLAG testing uses
as assembly as an example.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #43 from jyong at gcc dot gnu.org ---
Is it as simple as running the following?
<compile and link test>
${target}-objdump -j .debug_loclists -h a.exe | grep -q 0000000100000000

A return code 0 means potentially broken linker script is used.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #44 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yes.  Or maybe instead check that objdump -j .debug_loclists -h (or
.debug_rnglists) has both VMA and LMA all zeros instead?
Dunno what exactly that command prints in broken and what on correct binaries
on Windows (when using DWARF5).

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #45 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I have tried the mingw gcc/binutils crosses we have in Fedora (gcc 10.2.1) and
get:
i686-w64-mingw32-objdump -h ./pr98860.exe 

./pr98860.exe:     file format pei-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .debug_loclists 0000002a  00000000  00000000  00000448  2**0
                  CONTENTS, READONLY, DEBUGGING
  1 .debug_rnglists 00000013  00000000  00000000  00000648  2**0
                  CONTENTS, READONLY, DEBUGGING
  2 .text         000017d4  00401000  00401000  00000a00  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  3 .data         00000034  00403000  00403000  00002200  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .rdata        000008ec  00404000  00404000  00002400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .eh_frame     000008d0  00405000  00405000  00002e00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .bss          00000408  00406000  00406000  00000000  2**5
                  ALLOC
  7 .idata        00000588  00407000  00407000  00003800  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .CRT          00000034  00408000  00408000  00003e00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .tls          00000008  00409000  00409000  00004000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .debug_aranges 00000078  0040a000  0040a000  00004200  2**3
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_info   00003530  0040b000  0040b000  00004400  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_abbrev 0000063e  0040f000  0040f000  00007a00  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_line   00000795  00410000  00410000  00008200  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_frame  00000038  00411000  00411000  00008a00  2**2
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_str    00000360  00412000  00412000  00008c00  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_loc    0000039d  00413000  00413000  00009000  2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .debug_ranges 000000d8  00414000  00414000  00009400  2**0
                  CONTENTS, READONLY, DEBUGGING
so in that case it seems that .debug_{loclists,rnglists} etc. should use
non-zero VMA/LMA like other debug sections rather than zero like they currently
do.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #46 from jyong at gcc dot gnu.org ---
Is there a machine parsable output from objdump? I'm not sure if using gawk
would be OK. Such a test also won't work in build != host conditions.

I'm considering just having a notice in the gcc-11 release note to the
particular binutils commit/patch, so that anyone rolling their own toolchain
would be aware of it and try to apply the patch on binutils, since no released
version has the patch yet.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #47 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Does mingw/cygwin always use GNU binutils?
At least for ld.bfd, a quick and reliable test could be
$gcc_cv_ld --verbose 2>&1 | grep -q
'\.debug_loclists.*BLOCK.*__section_alignment__.*NOLOAD.*:'
&& $gcc_cv_ld --verbose 2>&1 | grep -q
'\.debug_rnglists.*BLOCK.*__section_alignment__.*NOLOAD.*:'
or so in configure.ac (for mingw/cygwin only, and AC_DEFINE a macro in that
case).

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #48 from jyong at gcc dot gnu.org ---
Now that's an interesting trick I never thought of.

There's LLVM based mingw, but I have never used nor do I know if it is relevant
here. Gold is ELF only as far as I know, so it would never be used. That should
leave only BFD ld.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #49 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50459&action=edit
gcc11-pr98860.patch

In that case this completely untested patch which could work, but no way to
really test it myself properly (nor have time to do that).
It needs testing both with bad and good binutils.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #50 from jyong at gcc dot gnu.org ---
I'll try testing it out over the next few days, thanks for the patch.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

jyong at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #50459|0                           |1
        is obsolete|                            |

--- Comment #51 from jyong at gcc dot gnu.org ---
Created attachment 50460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50460&action=edit
Slightly adjusted patch to fix errors

Adjust the patch to deal with xyes and silent result issues. Testing with older
binutils worked, -gdwarf-5 ignored, not sure if intentional.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #52 from jyong at gcc dot gnu.org ---
Oops I need retest with optimizations enabled to see the debug sections
emitted.
On the other hand, the new adjusted patch detects the binutils bug fine, tested
with new and old binutils.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #53 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Comment on attachment 50460
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50460
Slightly adjusted patch to fix errors

Thanks for fixing my bugs, but there is another one:
if (TARGET_PECOFF && opts_set->x_dwarf_version)
should have been really
if (TARGET_PECOFF && !opts_set->x_dwarf_version)
The intent was to make -gdwarf-4 the default for broken linker,
but still support -gdwarf-5 in the hope that when using it explictly, the user
has updated his linker.
Another option is to issue a warning or inform for the
#ifdef HAVE_LD_BROKEN_PE_DWARF5
if (TARGET_PECOFF && opts_set->x_dwarf_version && opts->x_dwarf_version >= 5)
case and reset it to -gdwarf-4.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #50460|0                           |1
        is obsolete|                            |

--- Comment #54 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50461&action=edit
gcc11-pr98860.patch

So the non-noisy version of the patch could be this.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #55 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50462&action=edit
gcc11-pr98860-2.patch

And the noisy variant this.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #56 from jyong at gcc dot gnu.org ---
OK, I've tested the patch from attachment 50461, seems to work fine:
gcc uses dwarf 4 by default if it does find a broken linker, but allows the
user to specify -gdwarf-5 if they want, resulting in a broken executable.
If the linker was found to be working at build time, dwarf-5 would be default.

I prefer the non-noisy patch because gcc doesn't actually detect the linker bug
at runtime, just silently doing what it thinks is best, which may not be
accurate if the user upgrades or downgrades binutils without a rebuild.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[rogero at howzatt dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #57 from Roger Orr <rogero at howzatt dot co.uk> ---
I've also confirmed the "non-noisy" patch  when used with binutils 2.35.2
(Sadly I've not yet manged to build binutils from source to try dwarf-5 with
the fix)

Many thanks.

I believe the "noisy" patch needs an edit in the line:

@@ -1861,6 +1861,15 @@ ix86_option_override_internal (bool main

which should be

@@ -1861,6 +1861,21 @@ ix86_option_override_internal (bool main

(at least, I can't apply it without that change...)

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #58 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

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

commit r11-7923-ga49a96f681bf13c6e77644d4507e867f00f93fe6
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 31 09:11:29 2021 +0200

    i386, debug: Default to -gdwarf-4 on Windows targets with broken ld.bfd
[PR98860]

    As mentioned in the PR, before the
   
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0
    fix from March 1st, PECOFF ld.bfd didn't know about .debug_loclists,
    .debug_rnglists and other debug sections new in DWARF 5.  Unfortunately,
    unlike for ELF linkers, that means the sections were placed in wrong
    ordering with wrong VMA/LMA, so the resulting executables are apparently
    unusable.

    As that is pretty new change, newer than 2.35.2 or 2.36 binutils releases,
    the following patch adds a workaround that turns -gdwarf-4 by default
    instead of -gdwarf-5 if a broken linker is found at configure time.
    Users can still explicitly play with -gdwarf-5 and either use a non-broken
    linker or use custom linker scripts for the broken one, but at least
    by default it should work.

    2021-03-31  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/98860
            * configure.ac (HAVE_LD_BROKEN_PE_DWARF5): New AC_DEFINE if PECOFF
            linker doesn't support DWARF sections new in DWARF5.
            * config/i386/i386-options.c (ix86_option_override_internal):
Default
            to dwarf_version 4 if HAVE_LD_BROKEN_PE_DWARF5 for TARGET_PECOFF
            targets.
            * config.in: Regenerated.
            * configure: Regenerated.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #59 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The non-noisy workaround applied.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860

--- Comment #60 from jyong at gcc dot gnu.org ---
Thanks all for debugging and finding a solution.