[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 Matthias Klose changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 --- Comment #9 from Matthias Klose --- that works again with the gcc-8 branch from 20200218. LTO link times however are about three hours.
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 --- Comment #8 from Richard Biener --- (In reply to Richard Biener from comment #7) > (In reply to Richard Biener from comment #3) > > I'm checking head with our GCC 8 build on armv7 which we build with > > --with-arch=armv7-a --with-tune=cortex-a15 --with-float=hard > > notably w/o --with-mode=thumb > > That worked fine here with 9eba9635f653291804ecb832e Oh, but we're not doing profiledbootstrap on arm (only aarch64).
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 --- Comment #7 from Richard Biener --- (In reply to Richard Biener from comment #3) > I'm checking head with our GCC 8 build on armv7 which we build with > --with-arch=armv7-a --with-tune=cortex-a15 --with-float=hard > notably w/o --with-mode=thumb That worked fine here with 9eba9635f653291804ecb832e
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 --- Comment #6 from Christophe Lyon --- I added --enable-default-pie to my configure options, and it's still successful.
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 Matthias Klose changed: What|Removed |Added CC||doko at ubuntu dot com --- Comment #5 from Matthias Klose --- I've started a new build with today's git branch. This is again a compiler configured with --enable-default-pie, and other hardening flags turned on by default: /usr/lib/gcc/arm-linux-gnueabihf/8/cc1 -quiet -v -imultiarch arm-linux-gnueabihf foo.c -quiet -dumpbase foo.c -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -march=armv7-a+fp -auxbase foo -version -fstack-protector-strong -Wformat -Wformat-security
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 --- Comment #4 from Christophe Lyon --- It worked for me with gcc-8-branch at g:9eba9635f653291804ecb832eebe1ed96e3346ba Using: ../gcc/configure --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --with-build-config=bootstrap-lto make profiledbootstrap -j50 but that's on a armv8 processor.
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 --- Comment #3 from Richard Biener --- I'm checking head with our GCC 8 build on armv7 which we build with --with-arch=armv7-a --with-tune=cortex-a15 --with-float=hard notably w/o --with-mode=thumb
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Does this still happen with gcc-8 branch? This is one of the two P1s we have (== release blockers).
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-01-29 Ever confirmed|0 |1
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |8.4 --- Comment #1 from Richard Biener --- 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 ../../src/gcc/df-core.c:1594 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.
