* [Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
@ 2020-11-11 7:37 ` rguenth at gcc dot gnu.org
2020-11-11 7:39 ` marxin at gcc dot gnu.org
` (31 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-11 7:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |lto
Target| |mips64
Target Milestone|--- |10.3
Status|UNCONFIRMED |WAITING
CC| |rguenth at gcc dot gnu.org
Last reconfirmed| |2020-11-11
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
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?
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
2020-11-11 7:37 ` [Bug lto/97787] " rguenth at gcc dot gnu.org
@ 2020-11-11 7:39 ` marxin at gcc dot gnu.org
2020-11-11 14:14 ` bunk at stusta dot de
` (30 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-11-11 7:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
2020-11-11 7:37 ` [Bug lto/97787] " rguenth at gcc dot gnu.org
2020-11-11 7:39 ` marxin at gcc dot gnu.org
@ 2020-11-11 14:14 ` bunk at stusta dot de
2020-11-11 15:04 ` rguenth at gcc dot gnu.org
` (29 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: bunk at stusta dot de @ 2020-11-11 14:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Adrian Bunk <bunk at stusta dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bunk at stusta dot de
--- Comment #3 from Adrian Bunk <bunk at stusta dot de> ---
(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?
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (2 preceding siblings ...)
2020-11-11 14:14 ` bunk at stusta dot de
@ 2020-11-11 15:04 ` rguenth at gcc dot gnu.org
2020-11-12 18:52 ` bunk at stusta dot de
` (28 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-11 15:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (3 preceding siblings ...)
2020-11-11 15:04 ` rguenth at gcc dot gnu.org
@ 2020-11-12 18:52 ` bunk at stusta dot de
2020-11-13 8:35 ` [Bug target/97787] " rguenth at gcc dot gnu.org
` (27 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: bunk at stusta dot de @ 2020-11-12 18:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #5 from Adrian Bunk <bunk at stusta dot de> ---
(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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (4 preceding siblings ...)
2020-11-12 18:52 ` bunk at stusta dot de
@ 2020-11-13 8:35 ` rguenth at gcc dot gnu.org
2020-11-13 19:12 ` bunk at stusta dot de
` (26 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-13 8:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|lto |target
CC| |mfortune at gmail dot com
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (5 preceding siblings ...)
2020-11-13 8:35 ` [Bug target/97787] " rguenth at gcc dot gnu.org
@ 2020-11-13 19:12 ` bunk at stusta dot de
2020-11-16 12:30 ` rguenther at suse dot de
` (25 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: bunk at stusta dot de @ 2020-11-13 19:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (6 preceding siblings ...)
2020-11-13 19:12 ` bunk at stusta dot de
@ 2020-11-16 12:30 ` rguenther at suse dot de
2021-01-16 13:15 ` xry111 at mengyan1223 dot wang
` (24 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenther at suse dot de @ 2020-11-16 12:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
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?
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (7 preceding siblings ...)
2020-11-16 12:30 ` rguenther at suse dot de
@ 2021-01-16 13:15 ` xry111 at mengyan1223 dot wang
2021-01-16 13:31 ` xry111 at mengyan1223 dot wang
` (23 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-16 13:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #9 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
(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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (8 preceding siblings ...)
2021-01-16 13:15 ` xry111 at mengyan1223 dot wang
@ 2021-01-16 13:31 ` xry111 at mengyan1223 dot wang
2021-01-16 13:55 ` xry111 at mengyan1223 dot wang
` (22 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-16 13:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #10 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
(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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (9 preceding siblings ...)
2021-01-16 13:31 ` xry111 at mengyan1223 dot wang
@ 2021-01-16 13:55 ` xry111 at mengyan1223 dot wang
2021-01-16 14:10 ` xry111 at mengyan1223 dot wang
` (21 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-16 13:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #11 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (10 preceding siblings ...)
2021-01-16 13:55 ` xry111 at mengyan1223 dot wang
@ 2021-01-16 14:10 ` xry111 at mengyan1223 dot wang
2021-01-18 8:15 ` rguenth at gcc dot gnu.org
` (20 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-16 14:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #12 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
"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...
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (11 preceding siblings ...)
2021-01-16 14:10 ` xry111 at mengyan1223 dot wang
@ 2021-01-18 8:15 ` rguenth at gcc dot gnu.org
2021-01-22 12:04 ` xry111 at mengyan1223 dot wang
` (19 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-18 8:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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).
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (12 preceding siblings ...)
2021-01-18 8:15 ` rguenth at gcc dot gnu.org
@ 2021-01-22 12:04 ` xry111 at mengyan1223 dot wang
2021-01-22 13:19 ` rguenth at gcc dot gnu.org
` (18 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-22 12:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #14 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
(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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (13 preceding siblings ...)
2021-01-22 12:04 ` xry111 at mengyan1223 dot wang
@ 2021-01-22 13:19 ` rguenth at gcc dot gnu.org
2021-01-22 16:53 ` xry111 at mengyan1223 dot wang
` (17 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-22 13:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |UNCONFIRMED
Version|10.0 |10.2.0
Target|mips64 |mips64el-unknown-linux-gnua
| |bi64
Ever confirmed|1 |0
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (14 preceding siblings ...)
2021-01-22 13:19 ` rguenth at gcc dot gnu.org
@ 2021-01-22 16:53 ` xry111 at mengyan1223 dot wang
2021-01-23 12:17 ` xry111 at mengyan1223 dot wang
` (16 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-22 16:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #16 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
(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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (15 preceding siblings ...)
2021-01-22 16:53 ` xry111 at mengyan1223 dot wang
@ 2021-01-23 12:17 ` xry111 at mengyan1223 dot wang
2021-01-23 13:04 ` xry111 at mengyan1223 dot wang
` (15 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-23 12:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #17 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
Reported as https://sourceware.org/bugzilla/show_bug.cgi?id=27228
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (16 preceding siblings ...)
2021-01-23 12:17 ` xry111 at mengyan1223 dot wang
@ 2021-01-23 13:04 ` xry111 at mengyan1223 dot wang
2021-01-24 12:47 ` xry111 at mengyan1223 dot wang
` (14 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-23 13:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #18 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (17 preceding siblings ...)
2021-01-23 13:04 ` xry111 at mengyan1223 dot wang
@ 2021-01-24 12:47 ` xry111 at mengyan1223 dot wang
2021-01-25 8:19 ` rguenth at gcc dot gnu.org
` (13 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-24 12:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #19 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
gas has added a workaround. I'll test it tomorrow.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (18 preceding siblings ...)
2021-01-24 12:47 ` xry111 at mengyan1223 dot wang
@ 2021-01-25 8:19 ` rguenth at gcc dot gnu.org
2021-01-25 10:16 ` xry111 at mengyan1223 dot wang
` (12 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-25 8:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (19 preceding siblings ...)
2021-01-25 8:19 ` rguenth at gcc dot gnu.org
@ 2021-01-25 10:16 ` xry111 at mengyan1223 dot wang
2021-01-25 10:30 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-25 10:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #21 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
(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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (20 preceding siblings ...)
2021-01-25 10:16 ` xry111 at mengyan1223 dot wang
@ 2021-01-25 10:30 ` rguenth at gcc dot gnu.org
2021-01-25 10:49 ` [Bug lto/97787] " pinskia at gcc dot gnu.org
` (10 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-25 10:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
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)
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (21 preceding siblings ...)
2021-01-25 10:30 ` rguenth at gcc dot gnu.org
@ 2021-01-25 10:49 ` pinskia at gcc dot gnu.org
2021-01-25 11:05 ` xry111 at mengyan1223 dot wang
` (9 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-01-25 10:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|target |lto
CC| |pinskia at gcc dot gnu.org
--- Comment #23 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (22 preceding siblings ...)
2021-01-25 10:49 ` [Bug lto/97787] " pinskia at gcc dot gnu.org
@ 2021-01-25 11:05 ` xry111 at mengyan1223 dot wang
2021-01-25 11:22 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2021-01-25 11:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #24 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
(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
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (23 preceding siblings ...)
2021-01-25 11:05 ` xry111 at mengyan1223 dot wang
@ 2021-01-25 11:22 ` rguenth at gcc dot gnu.org
2021-04-08 12:02 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-25 11:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
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?
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (24 preceding siblings ...)
2021-01-25 11:22 ` rguenth at gcc dot gnu.org
@ 2021-04-08 12:02 ` rguenth at gcc dot gnu.org
2021-04-09 7:57 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-08 12:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.3 |10.4
--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.3 is being released, retargeting bugs to GCC 10.4.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (25 preceding siblings ...)
2021-04-08 12:02 ` rguenth at gcc dot gnu.org
@ 2021-04-09 7:57 ` rguenth at gcc dot gnu.org
2022-03-22 10:39 ` [Bug lto/97787] [10/11/12 " rguenth at gcc dot gnu.org
` (5 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-04-09 7:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org
Last reconfirmed|2020-11-11 00:00:00 |2021-04-09
Status|UNCONFIRMED |ASSIGNED
--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
Honza, please have a look at this PR.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11/12 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (26 preceding siblings ...)
2021-04-09 7:57 ` rguenth at gcc dot gnu.org
@ 2022-03-22 10:39 ` rguenth at gcc dot gnu.org
2022-03-22 11:19 ` xry111 at mengyan1223 dot wang
` (4 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-03-22 10:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
Honza?
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11/12 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (27 preceding siblings ...)
2022-03-22 10:39 ` [Bug lto/97787] [10/11/12 " rguenth at gcc dot gnu.org
@ 2022-03-22 11:19 ` xry111 at mengyan1223 dot wang
2022-03-22 11:33 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: xry111 at mengyan1223 dot wang @ 2022-03-22 11:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #29 from Xi Ruoyao <xry111 at mengyan1223 dot wang> ---
GNU ld has added a workaround for this. But I'm not sure what will happen
using other linkers (gold or lld).
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11/12 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (28 preceding siblings ...)
2022-03-22 11:19 ` xry111 at mengyan1223 dot wang
@ 2022-03-22 11:33 ` rguenth at gcc dot gnu.org
2022-03-22 11:43 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-03-22 11:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> ---
Maybe it's fixed on trunk with r12-7325-g2f59f067610f22
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11/12 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (29 preceding siblings ...)
2022-03-22 11:33 ` rguenth at gcc dot gnu.org
@ 2022-03-22 11:43 ` jakub at gcc dot gnu.org
2022-06-28 10:42 ` [Bug lto/97787] [10/11/12/13 " jakub at gcc dot gnu.org
2023-07-07 10:38 ` [Bug lto/97787] [11/12/13/14 " rguenth at gcc dot gnu.org
32 siblings, 0 replies; 34+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-03-22 11:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Does any *.o file being LTO linked together have > 64K sections?
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [10/11/12/13 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (30 preceding siblings ...)
2022-03-22 11:43 ` jakub at gcc dot gnu.org
@ 2022-06-28 10:42 ` jakub at gcc dot gnu.org
2023-07-07 10:38 ` [Bug lto/97787] [11/12/13/14 " rguenth at gcc dot gnu.org
32 siblings, 0 replies; 34+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-06-28 10:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.4 |10.5
--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
^ permalink raw reply [flat|nested] 34+ messages in thread* [Bug lto/97787] [11/12/13/14 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
2020-11-10 20:09 [Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) bunk at stusta dot de
` (31 preceding siblings ...)
2022-06-28 10:42 ` [Bug lto/97787] [10/11/12/13 " jakub at gcc dot gnu.org
@ 2023-07-07 10:38 ` rguenth at gcc dot gnu.org
32 siblings, 0 replies; 34+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-07-07 10:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.5 |11.5
--- Comment #33 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.
^ permalink raw reply [flat|nested] 34+ messages in thread