[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||build Summary|Bootstrap comparison|[11 Regression] Bootstrap |failure!|comparison failure! --- Comment #1 from Richard Biener --- Guess nobody will feel responsible without more info ... maybe you can bisect or provide a good initial hint (last known good rev. vs. this failing rev.)
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #2 from dave.anglin at bell dot net --- On 2020-10-12 2:18 a.m., rguenth at gcc dot gnu.org wrote: > Guess nobody will feel responsible without more info ... maybe you can bisect > or provide a good initial hint (last known good rev. vs. this failing rev.) Working on it.
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-10-12 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #3 from John David Anglin --- Current bisect status: git bisect start # bad: [1c56c143b2011080d8a4516f37f78f647b0ee258] c++: Fix member alias template in C++17 and up. [PR96805] git bisect bad 1c56c143b2011080d8a4516f37f78f647b0ee258 # good: [b5f24739632389d50903bfde6d1bfc06d522c56b] Daily bump. git bisect good b5f24739632389d50903bfde6d1bfc06d522c56b
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355
John David Anglin changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from John David Anglin ---
dave@atlas:~/gnu/gcc/gcc$ git bisect bad
6923255e35a3d54f2083ad0f67edebb3f1b86506 is the first bad commit
commit 6923255e35a3d54f2083ad0f67edebb3f1b86506
Author: Jakub Jelinek
Date: Wed Oct 7 10:55:35 2020 +0200
debug: Pass --gdwarf-N to assembler if fixed gas is detected during
configure
> > As for the test assembly, I'd say we should take
> > #define F void foo (void) {}
> > F
> > compile it with
> > gcc -S -O2 -g1 -dA -gno-as-loc-support -fno-merge-debug-strings
> > remove .cfi_* directives, remove the ret instruction, change @function
> > and @progbits to %function and %progbits, change .uleb128 to just
.byte,
> > I think all the values should be small enough, maybe change .value to
> > .2byte and .long to .4byte (whatever is most portable across different
> > arches and gas versions), simplify (shorten) strings and adjust
> > sizes, and do something with the .quad directives, that is dependent on
> > the address size, perhaps just take those attributes out and adjust
> > .debug_abbrev? Finally, remove all comments (emit them in the first
case
> > just to better understand the debug info).
>
> I'm afraid it is hard to avoid the .quad or .8byte.
> Here is a 64-bit address version that assembles fine by both x86_64 and
> aarch64 as.
> Unfortunately doesn't fail with broken gas versions with -gdwarf-2
without
> the nop, so we'll need at least a nop in there.
> Fortunately gcc/configure.ac already determines the right nop insn for
the
> target, in $insn.
> So I guess what we want next is have the 32-bit version of this with
.4byte
> instead of .8byte and just let's try to assemble both versions, first
> without -gdwarf-2 and the one that succeeds assemble again with -gdwarf-2
> and check for the duplicate .debug_line sections error.
Ok, here it is in patch form.
I've briefly tested it, with the older binutils I have around (no
--gdwarf-N
support), with latest gas (--gdwarf-N that can be passed to as even when
compiling C/C++ etc. code and emitting .debug_line) and latest gas with
Mark's fix
reverted (--gdwarf-N support, but can only pass it to as when assembling
user .s/.S files, not when compiling C/C++ etc.).
2020-10-07 Jakub Jelinek
* configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG,
HAVE_AS_WORKING_DWARF_4_FLAG): New tests.
* gcc.c (ASM_DEBUG_DWARF_OPTION): Define.
(ASM_DEBUG_SPEC): Use ASM_DEBUG_DWARF_OPTION instead of
"--gdwarf2". Use %{cond:opt1;:opt2} style.
(ASM_DEBUG_OPTION_DWARF_OPT): Define.
(ASM_DEBUG_OPTION_SPEC): Define.
(asm_debug_option): New variable.
(asm_options): Add "%(asm_debug_option)".
(static_specs): Add asm_debug_option entry.
(static_spec_functions): Add dwarf-version-gt.
(debug_level_greater_than_spec_func): New function.
* config/darwin.h (ASM_DEBUG_OPTION_SPEC): Define.
* config/darwin9.h (ASM_DEBUG_OPTION_SPEC): Redefine.
* config.in: Regenerated.
* configure: Regenerated.
gcc/config.in| 13 +++
gcc/config/darwin.h | 1 +
gcc/config/darwin9.h | 3 +
gcc/configure| 310 +++
gcc/configure.ac | 188 +++
gcc/gcc.c| 77 -
6 files changed, 588 insertions(+), 4 deletions(-)
dave@atlas:~/gnu/gcc/gcc$ as --version
GNU assembler (GNU Binutils for Debian) 2.35.1
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #5 from Jakub Jelinek --- So, how do they differ? The comparison should be ignoring debug sections...
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #6 from dave.anglin at bell dot net --- On 2020-10-15 3:58 p.m., jakub at gcc dot gnu.org wrote: > So, how do they differ? The comparison should be ignoring debug sections... It looks like the .s file name is in object: dave@atlas:~/gnu/gcc/objdir$ od -c ./stage3-gcc/ada/get_targ.o > get_targ.o-od3 dave@atlas:~/gnu/gcc/objdir$ od -c ./stage2-gcc/ada/get_targ.o > get_targ.o-od2 dave@atlas:~/gnu/gcc/objdir$ diff -u get_targ.o-od2 get_targ.o-od3 --- get_targ.o-od2 2020-10-15 16:08:17.703062592 -0400 +++ get_targ.o-od3 2020-10-15 16:08:09.323143051 -0400 @@ -234,7 +234,7 @@ 0007220 t - i n > \0 \0 \0 \0 t y p e s . a 0007240 d s \0 002 \0 \0 g e t _ t a r g . a 0007260 d s \0 002 \0 \0 e i n f o . a d s \0 -0007300 002 \0 \0 c c w T W 7 T P . s \0 001 \0 +0007300 002 \0 \0 c c F z K X f J . s \0 001 \0 0007320 \0 \0 \0 005 002 \0 \0 \0 \0 003 016 001 005 004 003 026 0007340 001 005 016 3 005 \b / 005 004 B 005 016 3 005 \b 0007360 / 005 004 B 005 016 3 005 \b / 005 004 B 005 016 3
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 Jakub Jelinek changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- In what section it is? I.e. readelf -Wa get_targ.o ?
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #8 from dave.anglin at bell dot net --- On 2020-10-15 4:18 p.m., jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||mark at gcc dot gnu.org > > --- Comment #7 from Jakub Jelinek --- > In what section it is? I.e. readelf -Wa get_targ.o ? > Looks like .debug_aranges: [13] .debug_aranges PROGBITS 000e27 20 00 0 0 1 [14] .rela.debug_aranges RELA 0030ac 18 0c I 21 13 4
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #9 from Jakub Jelinek --- Those are debug sections. So contrib/compare-debug should be stripping them. Or is this non-debug bootstrap where either both stage2 and stage3 are built with -g or none of them?
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #10 from dave.anglin at bell dot net --- On 2020-10-15 4:35 p.m., jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 > > --- Comment #9 from Jakub Jelinek --- > Those are debug sections. So contrib/compare-debug should be stripping them. > Or is this non-debug bootstrap where either both stage2 and stage3 are built > with -g or none of them? Both stage2 and stage3 were built with -g. The get_targ.o files are the same after they are stripped with strip.
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #11 from Mark Wielaard --- I don't understand why the .debug sections are compared in this case. But if they are then the diff comes from this gas issue: https://sourceware.org/bugzilla/show_bug.cgi?id=26740 Even though unused gas -g might emit the input file name in the file table in some situations. It is harmless but since the the generated assembly file name might be different between stage2 and stage3 you will see a diff. If this really is an issue I think a workaround might be to make sure that the .file 1 directive is emitted as early as possible.
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #12 from John David Anglin --- Created attachment 49382 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49382&action=edit .s file generated with stage3 compiler File 1 position looks similar to the example in binutils/26740.
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 Jakub Jelinek changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #13 from Jakub Jelinek --- *** This bug has been marked as a duplicate of bug 97451 ***
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 Jakub Jelinek changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #14 from Jakub Jelinek --- (In reply to Mark Wielaard from comment #11) > I don't understand why the .debug sections are compared in this case. > > But if they are then the diff comes from this gas issue: > https://sourceware.org/bugzilla/show_bug.cgi?id=26740 > > Even though unused gas -g might emit the input file name in the file table > in some situations. It is harmless but since the the generated assembly file > name might be different between stage2 and stage3 you will see a diff. > > If this really is an issue I think a workaround might be to make sure that > the .file 1 directive is emitted as early as possible. But what is the problematic line before .file 1? E.g. if I look at lbasename.s, I see: .file "lbasename.c" .text .Ltext0: .p2align 4 .globl unix_lbasename .type unix_lbasename, @function unix_lbasename: .LVL0: .LFB20: .file 1 "../../libiberty/lbasename.c" In any case, the change to use -gdwarf-* by default even when not compiling just assembly was based on the assumption that gas would in that case pretty much only change the format of the .debug_line section generated from .file/.loc directives, but certainly not append anything on top of that itself (e.g. append some stuff to the compiler emitted .debug* sections). So, if that is not the case, we either need to fix gas in a similar way how it has been changed before for compiler generated .debug_line, if gas starts generating something and then sees compiler generated .debug* sections, it should throw away everything as if -gdwarf-* only affected the default version. Or we need a different gas option to just change the default dwarf level but don't enable any other -gdwarf behavior of gas.
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #15 from Mark Wielaard --- (In reply to Jakub Jelinek from comment #14) > In any case, the change to use -gdwarf-* by default even when not compiling > just assembly was based on the assumption that gas would in that case pretty > much only change the format of the .debug_line section generated from > .file/.loc directives, but certainly not append anything on top of that > itself (e.g. append some stuff to the compiler emitted .debug* sections). Right, that was certainly the intention. I believe it is simply a bug is gas where a file is kept that isn't used and put into the file table anyway: https://sourceware.org/bugzilla/show_bug.cgi?id=26740#c1 There is already a patch to fix it: https://sourceware.org/pipermail/binutils/2020-October/113741.html We just have to double check with Nick this is really what his original code was intended to do.
