https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123888
Bug ID: 123888
Summary: [16 Regression] Firefox 147 miscompilation with
LTO+PGO on x86_64-linux
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Firefox seems to be miscompiled with LTO+PGO in Fedora, during startup it
segfaults in mozilla::net::nsStandardURL::Init.
I've reduced the problem a little bit, if everything in libxul.so is compiled
with -fno-lto except Unified_cpp_netwerk_base{3,4}.o, which are still -flto
-fprofile-use, then speculative devirtualization looks wrong in the
NewStandardURI function.
In particular, if I under debugger in:
0x00007fffe55b9032 <+498>: mov 0x0(%r13),%rax
0x00007fffe55b9036 <+502>: lea 0x531463(%rip),%rdx #
0x7fffe5aea4a0
<_ZThn24_N7mozilla3net13nsStandardURL16TemplatedMutatorIS1_E4InitEjiRK12nsTSubstringIcEPKcP6nsIURIPP13nsIURIMutator>
0x00007fffe55b903d <+509>: mov 0x18(%rax),%rax
0x00007fffe55b9041 <+513>: cmp %rdx,%rax
0x00007fffe55b9044 <+516>: je 0x7fffe2b330dc
<NewStandardURI()-44588388>
change temporarily $rdx not to be
_ZThn24_N7mozilla3net13nsStandardURL16TemplatedMutatorIS1_E4InitEjiRK12nsTSubstringIcEPKcP6nsIURIPP13nsIURIMutator,
then
it doesn't take the speculative devirtualization path and works, if I don't do
that, it ends up calling a method with NULL this pointer.
This was at least with r16-6809 but similar crash can be reproduced also with
r16-7068.
I'll attach preprocessed sources. The original commands to compile those with
preprocessor and warning related stuff removed is
g++ -o Unified_cpp_netwerk_base3.o -c -flto -flifetime-dse=1
-fstack-protector-strong -fstrict-flex-arrays=1 -fno-rtti
-fno-sized-deallocation -fno-aligned-new -ffunction-sections -fdata-sections
-fno-math-errno -fno-exceptions -fPIC -O2 -g1 -fstack-protector-strong -m64
-march=x86-64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -mtls-dialect=gnu2
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fpermissive -O3
-fomit-frame-pointer -funwind-tables -fno-strict-aliasing -ffp-contract=off
-fprofile-use -fprofile-correction -Wno-coverage-mismatch
Unified_cpp_netwerk_base3.ii
g++ -o Unified_cpp_netwerk_base4.o -c -flto -flifetime-dse=1
-fstack-protector-strong -fstrict-flex-arrays=1 -fno-rtti
-fno-sized-deallocation -fno-aligned-new -ffunction-sections -fdata-sections
-fno-math-errno -fno-exceptions -fPIC -O2 -g1 -fstack-protector-strong -m64
-march=x86-64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -mtls-dialect=gnu2
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fpermissive -O3
-fomit-frame-pointer -funwind-tables -fno-strict-aliasing -ffp-contract=off
-fprofile-use -fprofile-correction -Wno-coverage-mismatch
Unified_cpp_netwerk_base4.ii
but not sure how to convince the linker to LTO link just those two together (-r
and some option?).
g++ -fstack-protector-strong -fstrict-flex-arrays=1 -fno-rtti
-fno-sized-deallocation -fno-aligned-new -ffunction-sections -fdata-sections
-fno-math-errno -fno-exceptions -fPIC -O2 -g1 -fstack-protector-strong -m64
-march=x86-64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -mtls-dialect=gnu2
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fpermissive -O3
-fomit-frame-pointer -funwind-tables -shared -o libxul.so -flto=32
-flifetime-dse=1 Unified_cpp_netwerk_base{3,4}.o
doesn't do that. During the reproduction of course libxul.so is linked to
2300+ other objects (all -fno-lto except these two).
