Bug 91724 - [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
Summary: [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 8.3.1
: P1 normal
Target Milestone: 8.4
Assignee: Not yet assigned to anyone
Keywords: ice-on-valid-code
Depends on:
Reported: 2019-09-10 16:28 UTC by Matthias Klose
Modified: 2019-09-11 09:12 UTC (History)
4 users (show)

See Also:
Target: arm-linux-gnueabihf
Known to work: 8.3.0
Known to fail: 8.3.1
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Klose 2019-09-10 16:28:22 UTC
seen with r275519 on the gcc-8 branch, was working with r274599

/<<PKGBUILDDIR>>/src/libstdc++-v3/libsupc++/new:122:7: note: in a call to allocation function 'operator new []' declared here
 void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
during RTL pass: loop2_invariant
../../src/gcc/hash-table.h: In member function 'expand':
../../src/gcc/hash-table.h:768:1: internal compiler error: Segmentation fault
0x11fdceb ???
0x1abb283 ???
0x198d9dd ???
0x18abdf3 ???
0x18ac059 ???
0x18ac355 ???
0x18ac87d ???
0x150137d ???
0x1577a83 ???
0x1579017 ???
0x13d219f ???
0x13d3321 ???
0x13d32f1 ???
0x13d32f1 ???
0x13d33f5 ???
0x19e4e5b ???
0x19f6851 ???
0x1ae3a4f ???
0x122f56d ???
0x1234aed ???
Please submit a full bug report,
with preprocessed source if appropriate.

complete build log at

configured with

--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
Comment 1 Richard Biener 2019-09-11 09:12:18 UTC
Hmm, can you bisect this a bit?  It may be a latent issue is uncovered.
Disabling compare-debug might also help getting better backtraces.

Looks like loop-invariant has inconsistent DF state somehow.  In the


frame it is interesting to know the problem causing this.

Maybe the backtrace is also completely bogus since there shoud be no
hash-tables involved here...

P1 until we know some more.