I guess it succeeds when you do not enable -g?  Can you check if reverting
63a2bdbfb42628800a6999e98804928855592ce7 or 136256c32db63600168516e562441f73c26a187a helps?  That said, is 10.1.0 OK?

(In reply to Richard Biener from comment #1)
> I guess it succeeds when you do not enable -g?  Can you check if reverting
> 63a2bdbfb42628800a6999e98804928855592ce7 or
> 136256c32db63600168516e562441f73c26a187a helps?  That said, is 10.1.0 OK?

I bet 136256c32db63600168516e562441f73c26a187a should fix that.

(In reply to Richard Biener from comment #1)
> I guess it succeeds when you do not enable -g?

Still fails with -g0

(In reply to Richard Biener from comment #1)
> Can you check if reverting
> 63a2bdbfb42628800a6999e98804928855592ce7 or
> 136256c32db63600168516e562441f73c26a187a helps?  That said, is 10.1.0 OK?

(In reply to Martin Liška from comment #2)
> I bet 136256c32db63600168516e562441f73c26a187a should fix that.

Sorry for omitting more exact version information in the bug report.

Known-broken are all Debian gcc-10 packages since gcc 10 became default in Debian unstable, upstream this is the gcc-10 branch from 20200808 to 20201029.

This implies that the two mentioned commits did not break or fix it.

Is there any debug information I could gather that might be useful for you?

Hmm, the final linker input, namely /tmp/bibletime.kNyaLB.ltrans9.ltrans.o
would be a start.  Adding -save-temps should eventually retain it (but likely
somewhere else with a different name).

You can also try to 'reduce' the testcase.  Since you are linking a shared
object you can try to strip as many linker inputs as possible and then
reduce the source files.  creduce or multi-delta or cvise might help you
here.  Eventually Martin can help but I don't think the compile-farm has
a mips64 machine.

(In reply to Richard Biener from comment #4)
> You can also try to 'reduce' the testcase.  Since you are linking a shared
> object you can try to strip as many linker inputs as possible and then
> reduce the source files.

Bisecting does not work when both halves are working, but I now found some clues:

$ g++ -flto -shared CMakeFiles/cpp.dir/src/dolfin.cpp.o CMakeFiles/cpp.dir/src/parameter.cpp.o CMakeFiles/cpp.dir/src/adaptivity.cpp.o CMakeFiles/cpp.dir/src/ale.cpp.o CMakeFiles/cpp.dir/src/common.cpp.o CMakeFiles/cpp.dir/src/fem.cpp.o CMakeFiles/cpp.dir/src/function.cpp.o CMakeFiles/cpp.dir/src/generation.cpp.o CMakeFiles/cpp.dir/src/geometry.cpp.o CMakeFiles/cpp.dir/src/graph.cpp.o CMakeFiles/cpp.dir/src/log.cpp.o CMakeFiles/cpp.dir/src/math.cpp.o CMakeFiles/cpp.dir/src/mesh.cpp.o CMakeFiles/cpp.dir/src/multistage.cpp.o CMakeFiles/cpp.dir/src/ts.cpp.o CMakeFiles/cpp.dir/src/io.cpp.o CMakeFiles/cpp.dir/src/la.cpp.o CMakeFiles/cpp.dir/src/nls.cpp.o CMakeFiles/cpp.dir/src/refinement.cpp.o CMakeFiles/cpp.dir/src/MPICommWrapper.cpp.o
/usr/bin/ld: /tmp/ccofV1SZ.ltrans32.ltrans.o: .symtab local symbol at index 214 (>= sh_info of 34)
/usr/bin/ld: /tmp/ccofV1SZ.ltrans32.ltrans.o: error adding symbols: bad value
collect2: error: ld returned 1 exit status
$  g++ -flto -shared dolfin.ii parameter.ii adaptivity.ii ale.ii common.ii fem.ii function.ii generation.ii geometry.ii graph.ii log.ii math.ii mesh.ii multistage.ii ts.ii io.ii la.ii nls.ii refinement.ii MPICommWrapper.ii
/tmp/ccraiNyo.ltrans9.ltrans.o: in function `std::__exception_ptr::exception_ptr::operator=(std::__exception_ptr::exception_ptr&&)':
<artificial>:(.text+0x290): relocation truncated to fit: R_MIPS_CALL16 against `std::__exception_ptr::exception_ptr::~exception_ptr()@@CXXABI_1.3.3'
/tmp/ccraiNyo.ltrans9.ltrans.o: in function `std::__cxx11::to_string(int)':
<artificial>:(.text+0x414): relocation truncated to fit: R_MIPS_CALL16 against `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(unsigned long, char, std::allocator<char> const&)@@GLIBCXX_3.4.21'
<artificial>:(.text+0x42c): relocation truncated to fit: R_MIPS_CALL16 against `std::allocator<char>::~allocator()@@GLIBCXX_3.4'
<artificial>:(.text+0x498): relocation truncated to fit: R_MIPS_CALL16 against `std::allocator<char>::~allocator()@@GLIBCXX_3.4'
<artificial>:(.text+0x4b0): relocation truncated to fit: R_MIPS_CALL16 against `_Unwind_Resume@@GCC_3.0'
<artificial>:(.text+0x4e0): relocation truncated to fit: R_MIPS_CALL16 against `_Unwind_Resume@@GCC_3.0'
/tmp/ccraiNyo.ltrans9.ltrans.o: in function `std::__cxx11::to_string(unsigned long)':
<artificial>:(.text+0x584): relocation truncated to fit: R_MIPS_CALL16 against `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(unsigned long, char, std::allocator<char> const&)@@GLIBCXX_3.4.21'
<artificial>:(.text+0x598): relocation truncated to fit: R_MIPS_CALL16 against `std::allocator<char>::~allocator()@@GLIBCXX_3.4'
<artificial>:(.text+0x5c8): relocation truncated to fit: R_MIPS_CALL16 against `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::size() const@@GLIBCXX_3.4.21'
<artificial>:(.text+0x610): relocation truncated to fit: R_MIPS_CALL16 against `std::allocator<char>::~allocator()@@GLIBCXX_3.4'
<artificial>:(.text+0x628): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
$ g++ -flto -shared dolfin.ii parameter.ii adaptivity.ii ale.ii common.ii fem.ii function.ii generation.ii geometry.ii graph.ii log.ii math.ii mesh.ii multistage.ii ts.ii io.ii la.ii nls.ii refinement.ii MPICommWrapper.ii -mxgot
$ g++ -flto -shared CMakeFiles/cpp.dir/src/dolfin.cpp.o CMakeFiles/cpp.dir/src/parameter.cpp.o CMakeFiles/cpp.dir/src/adaptivity.cpp.o CMakeFiles/cpp.dir/src/ale.cpp.o CMakeFiles/cpp.dir/src/common.cpp.o CMakeFiles/cpp.dir/src/fem.cpp.o CMakeFiles/cpp.dir/src/function.cpp.o CMakeFiles/cpp.dir/src/generation.cpp.o CMakeFiles/cpp.dir/src/geometry.cpp.o CMakeFiles/cpp.dir/src/graph.cpp.o CMakeFiles/cpp.dir/src/log.cpp.o CMakeFiles/cpp.dir/src/math.cpp.o CMakeFiles/cpp.dir/src/mesh.cpp.o CMakeFiles/cpp.dir/src/multistage.cpp.o CMakeFiles/cpp.dir/src/ts.cpp.o CMakeFiles/cpp.dir/src/io.cpp.o CMakeFiles/cpp.dir/src/la.cpp.o CMakeFiles/cpp.dir/src/nls.cpp.o CMakeFiles/cpp.dir/src/refinement.cpp.o CMakeFiles/cpp.dir/src/MPICommWrapper.cpp.o -flto-partition=none
$ 

Adding -mxgot to compiler and linker flags of a normal LTO build does not work, but -flto-partition=none during linking is a workaround.

I see.  Still GCC or GAS produces a bogus object file (the original linker error).  It might be the new problem is an entirely different one?  It looks
more and more like a target problem to me.

CCing the mips maintainer.

(In reply to Richard Biener from comment #6)
> I see.  Still GCC or GAS produces a bogus object file (the original linker
> error).  It might be the new problem is an entirely different one?  It looks
> more and more like a target problem to me.

My guess would be that the situations where -mxgot is required on 64bit MIPS are not (no longer?) handled properly with LTO.

Note that when compiling from precompiled sources the linker also exits with an error, the main difference in that case is that the correct "relocation truncated to fit" error message is not output in the LTO case.

More worrisome is that adding -mxgot to compiler and linker flags did not fix it in the LTO case.

On Fri, 13 Nov 2020, bunk at stusta dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
> 
> --- Comment #7 from Adrian Bunk <bunk at stusta dot de> ---
> (In reply to Richard Biener from comment #6)
> > I see.  Still GCC or GAS produces a bogus object file (the original linker
> > error).  It might be the new problem is an entirely different one?  It looks
> > more and more like a target problem to me.
> 
> My guess would be that the situations where -mxgot is required on 64bit MIPS
> are not (no longer?) handled properly with LTO.
> 
> Note that when compiling from precompiled sources the linker also exits with an
> error, the main difference in that case is that the correct "relocation
> truncated to fit" error message is not output in the LTO case.
> 
> More worrisome is that adding -mxgot to compiler and linker flags did not fix
> it in the LTO case.

I guess it is because -mxgot is supposed to be handled by the assembler?
I see

%{mgp32} %{mgp64} %{march=*} %{mxgot:-xgot} \

in ASM_SPEC.  I guess this doesn't make it to COLLECT_AS_OPTIONS
and eventually makes it dropped from COLLECT_GCC_OPTIONS as well.

Can you attach the full output of compiling & linking with -v added?

Can you try using -mxgot -Wa,-xgot or -mxgot -Xassembler -xgot at
compile time?

(In reply to rguenther@suse.de from comment #8)

> I guess it is because -mxgot is supposed to be handled by the assembler?
> I see
> 
> %{mgp32} %{mgp64} %{march=*} %{mxgot:-xgot} \
> 
> in ASM_SPEC.  I guess this doesn't make it to COLLECT_AS_OPTIONS
> and eventually makes it dropped from COLLECT_GCC_OPTIONS as well.

I don't think so.

I can reproduce this issue compiling spidermonkey (js interpreter) from firefox-78 ESR.  I'm using "-pipe" so I can easily find the parameters passed to "as", using "ps -aux".  "-xgot" is passed correctly.

> Can you attach the full output of compiling & linking with -v added?
>
> Can you try using -mxgot -Wa,-xgot or -mxgot -Xassembler -xgot at
> compile time?

I'm trying, though my gut feeling is that it won't work.

(In reply to Xi Ruoyao from comment #9)
> (In reply to rguenther@suse.de from comment #8)
> > Can you try using -mxgot -Wa,-xgot or -mxgot -Xassembler -xgot at
> > compile time?
> 
> I'm trying, though my gut feeling is that it won't work.

There is no luck. "-mxgot -Wa,-xgot" gives the same error.

In my case the error message is:

/usr/bin/ld: js.ltrans2.ltrans.o: .symtab local symbol at index 1411 (>= sh_info of 404) 
/usr/bin/ld: js.ltrans2.ltrans.o: error adding symbols: bad value

I've uploaded the "guilty" files, js.ltrans2.* to my server, at

https://bf.mengyan1223.wang/assets/gcc-97787/

so someone can analysis it.

"readelf -s js.ltrans2.ltrans.o" gives a strange unnamed UND symbol:

  1411: 0000000000000000     0 SECTION LOCAL  DEFAULT  UND 

I'm not sure what's happening...

(In reply to Xi Ruoyao from comment #9)
> (In reply to rguenther@suse.de from comment #8)
> 
> > I guess it is because -mxgot is supposed to be handled by the assembler?
> > I see
> > 
> > %{mgp32} %{mgp64} %{march=*} %{mxgot:-xgot} \
> > 
> > in ASM_SPEC.  I guess this doesn't make it to COLLECT_AS_OPTIONS
> > and eventually makes it dropped from COLLECT_GCC_OPTIONS as well.
> 
> I don't think so.
> 
> I can reproduce this issue compiling spidermonkey (js interpreter) from
> firefox-78 ESR.  I'm using "-pipe" so I can easily find the parameters
> passed to "as", using "ps -aux".  "-xgot" is passed correctly.
> 
> > Can you attach the full output of compiling & linking with -v added?

^^^ (output aka output on the console)

I think the issue should be visible from a simple hello world compiled
with LTO and -mxgot (aka not using -xgot in the approproate places in the
end, not failing the link in the end).

(In reply to Richard Biener from comment #13)
> (In reply to Xi Ruoyao from comment #9)
> > (In reply to rguenther@suse.de from comment #8)
> > 
> > > I guess it is because -mxgot is supposed to be handled by the assembler?
> > > I see
> > > 
> > > %{mgp32} %{mgp64} %{march=*} %{mxgot:-xgot} \
> > > 
> > > in ASM_SPEC.  I guess this doesn't make it to COLLECT_AS_OPTIONS
> > > and eventually makes it dropped from COLLECT_GCC_OPTIONS as well.
> > 
> > I don't think so.
> > 
> > I can reproduce this issue compiling spidermonkey (js interpreter) from
> > firefox-78 ESR.  I'm using "-pipe" so I can easily find the parameters
> > passed to "as", using "ps -aux".  "-xgot" is passed correctly.
> > 
> > > Can you attach the full output of compiling & linking with -v added?
> 
> ^^^ (output aka output on the console)

Reproduced again, building libsass.

The output without -mxgot: https://bf.mengyan1223.wang/assets/gcc-97787/libsass_so_lto_output.tar.xz

The output with -mxgot: https://bf.mengyan1223.wang/assets/gcc-97787/libsass_so_lto_output_mxgot.tar.xz

Full console output with --verbose is included in the tarballs, named console.log.

> I think the issue should be visible from a simple hello world compiled
> with LTO and -mxgot (aka not using -xgot in the approproate places in the
> end, not failing the link in the end).

Actually I don't think it's a xgot issue... With or without -mxgot I got exactly same error message.

So I see that

   242: 0000000000000000     0 SECTION LOCAL  DEFAULT  UND 

and that's indeed broken (UND SECTION?)  but ld complains that the SECTION
type is after the last section entry.  So next up would be to look at the
assembly file the compiler generates for libsass.so.1.0.0.ltrans16.ltrans.o.

The console output shows how it's generated:

 as -v -EL -mips64r2 -mips64r2 -mmsa -mloongson-ext -mloongson-ext -mloongson-ext2 -mloongson-ext2 -O2 -mabi=64 -mabi=64 -march=gs464e -march=gs464e -march=gs464e -mtune=gs464e -mtune=gs464e -mtune=gs464e -KPIC -o libsass.so.1.0.0.ltrans16.ltrans.o libsass.so.1.0.0.ltrans16.s

and the "last" section I see in there is

        .section        .note.GNU-stack,"",@progbits

and I can confirm that GNU as (2.35.1) produces an object with the strange
section (using a cross binutils).  I think that no valid assembly file
should produce that so may I suggest to file a bug at sourceware for an
assembler issue? (just use the libsass.so.1.0.0.ltrans16.s file as testcase)

Maybe there's more mips people around than here.

(In reply to Richard Biener from comment #15)
> So I see that
> 
>    242: 0000000000000000     0 SECTION LOCAL  DEFAULT  UND 
> 
> and that's indeed broken (UND SECTION?)  but ld complains that the SECTION
> type is after the last section entry.  So next up would be to look at the
> assembly file the compiler generates for libsass.so.1.0.0.ltrans16.ltrans.o.
> 
> The console output shows how it's generated:
> 
>  as -v -EL -mips64r2 -mips64r2 -mmsa -mloongson-ext -mloongson-ext
> -mloongson-ext2 -mloongson-ext2 -O2 -mabi=64 -mabi=64 -march=gs464e
> -march=gs464e -march=gs464e -mtune=gs464e -mtune=gs464e -mtune=gs464e -KPIC
> -o libsass.so.1.0.0.ltrans16.ltrans.o libsass.so.1.0.0.ltrans16.s
> 
> and the "last" section I see in there is
> 
>         .section        .note.GNU-stack,"",@progbits
> 
> and I can confirm that GNU as (2.35.1) produces an object with the strange
> section (using a cross binutils).  I think that no valid assembly file
> should produce that so may I suggest to file a bug at sourceware for an
> assembler issue? (just use the libsass.so.1.0.0.ltrans16.s file as testcase)
> 
> Maybe there's more mips people around than here.

I managed to make a smallest testcase (by removing lines in ltrans16.s) to generate such a buggy section:

	.text
foo:
	.reloc	1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0
1:	nop

I'm not a toolchain expert.  If you believe it looks like a gas bug, let's report it to gas.

Reported as https://sourceware.org/bugzilla/show_bug.cgi?id=27228

Oh no.  Now I think it's GCC side.

According to gas doc

https://sourceware.org/binutils/docs/as/Symbol-Names.html#Symbol-Names

.LTHUNK5.lto_priv.0 should be a local label.  But in our LTO output, this label is defined in libsass.so.1.0.0.ltrans1.s and used in other ltrans files.

gas has added a workaround.  I'll test it tomorrow.

Indeed already the name, .LTHUNK5.lto_priv.0, hints at that this should be a local symbol.  Not sure why we end up with a .reloc then.

        ld      $25,%got_disp(.LTHUNK5.lto_priv.0)($28)
.LEHB26 = .
        .reloc  1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0
1:      jalr    $25

this seems to be in _ZN4Sass6Parser16parse_parametersEv

Maybe it's possible to reduce the testcase by bisecting the object files
necessary to produce the bogus LTRANS assembly?  From that one can start
reducing the source of the necessary object files.

Another interesting bit would be to see the IPA dumps of the broken LTRANS
unit.  If you add -fdump-ipa-all-details to the link command you should get
dump files alongside the ltrans temp files.

(In reply to Richard Biener from comment #20)
> Indeed already the name, .LTHUNK5.lto_priv.0, hints at that this should be a
> local symbol.  Not sure why we end up with a .reloc then.
> 
>         ld      $25,%got_disp(.LTHUNK5.lto_priv.0)($28)
> .LEHB26 = .
>         .reloc  1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0
> 1:      jalr    $25
> 
> this seems to be in _ZN4Sass6Parser16parse_parametersEv
> 
> Maybe it's possible to reduce the testcase by bisecting the object files
> necessary to produce the bogus LTRANS assembly?  From that one can start
> reducing the source of the necessary object files.
> 
> Another interesting bit would be to see the IPA dumps of the broken LTRANS
> unit.  If you add -fdump-ipa-all-details to the link command you should get
> dump files alongside the ltrans temp files.

I can confirm that the workaround in gas (released in binutils-2.36) "fixes" the problem.

Some function aliases named ".LTHUNK%d" are created in C++ FE (cp/method.c, L232).  With LTO those are cloned as ".LTHUNK%d.lto_priv.%d".

Functions aliases should not be named ".xxx" IMO.  Perhaps names like __gcc_lthunk.%d is better.

There is target specific sanitizing of symbol names - if the name is really the issue then it should be _much_ more prevalent since all IPA cloning uses
dots as well.  clone_function_name produces them and ASM_FORMAT_PRIVATE_NAME
is the "sanitizer" that's supposed to mangle it to correct form.  But as the
name suggests the definition of a local private symbol isn't supposed to go
away without all of its uses so the real issue must be elsewhere in optimization.
(thus asking for IPA dumps, specifically the .000i.cgraph dump which should
mention when the compiler thinks the .LTHUNK5.lto_priv.0 goes away)

(In reply to Richard Biener from comment #20)
> Indeed already the name, .LTHUNK5.lto_priv.0, hints at that this should be a
> local symbol.  Not sure why we end up with a .reloc then.
> 
>         ld      $25,%got_disp(.LTHUNK5.lto_priv.0)($28)
> .LEHB26 = .
>         .reloc  1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0
> 1:      jalr    $25
> 
> this seems to be in _ZN4Sass6Parser16parse_parametersEv

So 64bit MIPS n64 ABI with -mxgot does all function calls via loading an address from the GOT, the .reloc there is to say to the linker to see if it can relax it to be a direct jump (with link) rather than the indirect jump.

Looking into the cp/method.c code, I see we are creating an alias called .LTHUNK5 for a function which seems to be fine.  So either we are not outputing the correct name or the way local aliases are not being handled correctly when splitting up the LTO partitions; -flto-partition=none is a hint there.

(In reply to Richard Biener from comment #22)
> There is target specific sanitizing of symbol names - if the name is really
> the issue then it should be _much_ more prevalent since all IPA cloning uses
> dots as well.  clone_function_name produces them and ASM_FORMAT_PRIVATE_NAME
> is the "sanitizer" that's supposed to mangle it to correct form.  But as the
> name suggests the definition of a local private symbol isn't supposed to go
> away without all of its uses so the real issue must be elsewhere in
> optimization.
> (thus asking for IPA dumps, specifically the .000i.cgraph dump which should
> mention when the compiler thinks the .LTHUNK5.lto_priv.0 goes away)

IPA dumps (along with .ltrans* files) are uploaded: https://bf.mengyan1223.wang/assets/gcc-97787/libsass_lto_ipa_dump.tar.xz

OK, so it's read as

*.LTHUNK5.lto_priv.0/2880 (*.LTHUNK5) @0xfff1163840
  Type: function definition analyzed alias
  Visibility: in_other_partition used_from_other_partition prevailing_def_ironly external public visibility_specified visibility:hidden artificial
  References: _ZN4Sass10Parameters20adjust_after_pushingENS_10SharedImplINS_9ParameterEEE/2879 (alias)
  Referring:
  Read from file: libsass.so.1.0.0.ltrans16.o
  Unit id: 3
  Function flags:
  Called by: _ZThn64_N4Sass10Parameters20adjust_after_pushingENS_10SharedImplINS_9ParameterEEE/349153 (can throw external) _ZThn64_N4Sass10Parameters20adjust_after_pushingENS_10SharedImplINS_9ParameterEEE/2881 (can throw external)
  Calls:

and thus indeed "external" (in_other_partition).  Defined in ltrans1.s as

        .globl  .LTHUNK5.lto_priv.0
        .hidden .LTHUNK5.lto_priv.0
        .LTHUNK5.lto_priv.0 = _ZN4Sass10Parameters20adjust_after_pushingENS_10SharedImplINS_9ParameterEEE

which I think means that possibly the process of bringing a symbol local
needs to mangle the assembler name before using it more thoroughly or the
mips target in particular needs to introduce the extern symbol to the
assembler to not confuse it with a local label.  I think the latter is
more likely - Honza should know if other targets (like AIX ...) are
affected similarly and what we have to do here.

Honza?

GCC 10.3 is being released, retargeting bugs to GCC 10.4.

Honza, please have a look at this PR.

Honza?

GNU ld has added a workaround for this.  But I'm not sure what will happen using other linkers (gold or lld).

Maybe it's fixed on trunk with r12-7325-g2f59f067610f22

Does any *.o file being LTO linked together have > 64K sections?

GCC 10.4 is being released, retargeting bugs to GCC 10.5.

GCC 10 branch is being closed.