[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #17 from Matt Godbolt --- This is proprietary code (that the App and Sentry files didn't really contain anything I was concerned about), and it links with a number of other libraries which are much more proprietary (e.g. lwave env/lib/libwave.so -lsentry); so unfortunately I can't do more on my side. I'm really sorry, and appreciate the time you've taken so far but short of releasing all the source and binaries I fear I'll end up sending all our code. Our workaround is to pass `-g` unconditionally. If folks have ideas for minimizing this, or even debug steps I could try locally, I will try and find time to do so (outside of work hours, though).
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #16 from Martin Liška --- Ok, so please provide pre-processed files for all stuff that goes to libwave_common.a library. And the same for main.o please.
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #15 from Matt Godbolt --- > Can you please try reproducing it locally with the 2 pre-processed file. I'm not sure how to: if I don't have all the object files available in my link line I get missing symbol errors before any lto1 invocation. Any ideas? > And can you please share the full linker command line (I posted only the lto1 > invocation). The two files I posted were placed into a library with other files with the command: ``` "/home/mgodbolt/dev/wave/cmake-build-release/env/bin/x86_64-conda_cos6-linux-gnu-gcc-ar" cr src/wave/common/libwave_common.a src/wave/common/CMakeFiles/wave_common.dir/App.cpp.o src/wave/common/CMakeFiles/wave_common.dir/Endpoint.cpp.o src/wave/common/CMakeFiles/wave_common.dir/LineReader.cpp.o src/wave/common/CMakeFiles/wave_common.dir/NodeMerger.cpp.o src/wave/common/CMakeFiles/wave_common.dir/ParseTimestamp.cpp.o src/wave/common/CMakeFiles/wave_common.dir/Price.cpp.o src/wave/common/CMakeFiles/wave_common.dir/Sentry.cpp.o src/wave/common/CMakeFiles/wave_common.dir/TempDirectory.cpp.o src/wave/common/CMakeFiles/wave_common.dir/parse_byte_size.cpp.o && "/home/mgodbolt/dev/wave/cmake-build-release/env/bin/x86_64-conda_cos6-linux-gnu-gcc-ranlib" src/wave/common/libwave_common.a ``` The full link command we called that internally called lto1 and exhibits the issue is: ``` /home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/bin/x86_64-conda_cos6-linux-gnu-g++ src/binaries/gap_report/CMakeFiles/gap_report.dir/main.cpp.o -o src/binaries/gap_report/gap_report -L/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/lib -Wl,-rpath,/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/lib:/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/src/tradewinds: src/tradewinds/libtradewinds.so env/lib/libwave_common.a -lwave -lfmt env/lib/libwave.so -lstdc++fs -lsentry -lfmt ``` the `env/lib/libwave_common.a` referenced here is the A file, that as part of its output calls lto1. I ran that command with `-v` : ``` cy2-desktop-37:~/d/t/cmake-build-sanitize ((97)|✔) $ /home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/bin/x86_64-conda_cos6-linux-gnu-g++ -vsrc/binaries/gap_report/CMakeFiles/gap_report.dir/main.cpp.o -o src/binaries/gap_report/gap_report -L/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/lib -Wl,-rpath,/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/lib:/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/src/tradewinds: src/tradewinds/libtradewinds.so env/lib/libwave_common.a -lwave -lfmt env/lib/libwave.so -lstdc++fs -lsentry -lfmt Reading specs from /envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/specs COLLECT_GCC=/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/bin/x86_64-conda_cos6-linux-gnu-g++ COLLECT_LTO_WRAPPER=/envy/tradewinds/38/e526c9ac3dd516/bin/../libexec/gcc/x86_64-conda-linux-gnu/9.3.0/lto-wrapper Target: x86_64-conda-linux-gnu Configured with: /home/conda/feedstock_root/build_artifacts/ctng-compilers_1618239181388/work/.build/x86_64-conda-linux-gnu/src/gcc/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=x86_64-conda-linux-gnu --prefix=/home/conda/feedstock_root/build_artifacts/ctng-compilers_1618239181388/work/gcc_built --with-sysroot=/home/conda/feedstock_root/build_artifacts/ctng-compilers_1618239181388/work/gcc_built/x86_64-conda-linux-gnu/sysroot --enable-languages=c,c++,fortran,objc,obj-c++ --with-pkgversion='crosstool-NG 1.24.0.133_b0863d8_dirty' --enable-__cxa_atexit --disable-libmudflap --enable-libgomp --disable-libssp --enable-libquadmath --enable-libquadmath-support --enable-libsanitizer --enable-libmpx --with-gmp=/home/conda/feedstock_root/build_artifacts/ctng-compilers_1618239181388/work/.build/x86_64-conda-linux-gnu/buildtools --with-mpfr=/home/conda/feedstock_root/build_artifacts/ctng-compilers_1618239181388/work/.build/x86_64-conda-linux-gnu/buildtools --with-mpc=/home/conda/feedstock_root/build_artifacts/ctng-compilers_1618239181388/work/.build/x86_64-conda-linux-gnu/buildtools --with-isl=/home/conda/feedstock_root/build_artifacts/ctng-compilers_1618239181388/work/.build/x86_64-conda-linux-gnu/buildtools --enable-lto --enable-threads=posix --enable-target-optspace --enable-plugin --enable-gold --disable-nls --disable-multilib --with-local-prefix=/home/conda/feedstock_root/build_artifacts/ctng-compilers_1618239181388/work/gcc_built/x86_64-conda-linux-gnu/sysroot --enable-long-long --enable-default-pie Thread model: posix gcc version 9.3.0 (crosstool-NG 1.24.0.133_b0863d8_dirty) COMPILER_PATH=/envy/tradewinds/38/e526c9ac3dd516/bin/../libexec/gcc/x86_64-conda-linux-gnu/9.3.0/:/envy/tradewinds/38/e526c9ac3dd516/bin/../libexec/gcc/:/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #14 from Martin Liška --- (In reply to Matt Godbolt from comment #13) > Both attached. When they're built they're built with: > > ``` > /home/mgodbolt/dev/wave/cmake-build-release/env/bin/x86_64-conda_cos6-linux- > gnu-g++ -DSPDLOG_FMT_EXTERNAL -Igenerated -I../src > -I../src/wave/common/../.. -Isrc/wave -I../src/wave/.. -isystem env/include > -O3 -DNDEBUG -flto -fno-fat-lto-objects -include > /home/mgodbolt/dev/wave/cmake-build-release/conda_env.hpp -fconcepts -Wall > -Wextra -Werror -g -fPIC -fvisibility-inlines-hidden -march=skylake > -Wconversion -Wsign-conversion -Wnon-virtual-dtor -Wold-style-cast > -Wpedantic -Wuseless-cast -Wdouble-promotion -Wcast-align -Wduplicated-cond > -Wlogical-op -Wrestrict -Wnull-dereference -pedantic -std=gnu++17 -MD -MT > src/wave/common/CMakeFiles/wave_common.dir/App.cpp.o -MF > src/wave/common/CMakeFiles/wave_common.dir/App.cpp.o.d -o > src/wave/common/CMakeFiles/wave_common.dir/App.cpp.o -c > ../src/wave/common/App.cpp > ``` > > The attachments were created by putting -E at the end of the line, changing > the `-o` location, then gzipping the output. Thanks for it, unfortunately, I can't reproduce it with: $ g++ -O3 -DNDEBUG -flto -fno-fat-lto-objects -fconcepts -Wall -Wextra -Werror -g -fPIC -fvisibility-inlines-hidden -march=skylake -Wconversion -Wsign-conversion -Wnon-virtual-dtor -Wold-style-cast -Wpedantic -Wuseless-cast -Wdouble-promotion -Wcast-align -Wduplicated-cond -Wlogical-op -Wrestrict -Wnull-dereference -pedantic -std=gnu++17 App.ii Sentry.ii -c $ g++ Sentry.o App.o -shared -flto with: gcc --version gcc (GCC) 9.4.1 20210825 Can you please try reproducing it locally with the 2 pre-processed file. And can you please share the full linker command line (I posted only the lto1 invocation).
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #13 from Matt Godbolt --- Both attached. When they're built they're built with: ``` /home/mgodbolt/dev/wave/cmake-build-release/env/bin/x86_64-conda_cos6-linux-gnu-g++ -DSPDLOG_FMT_EXTERNAL -Igenerated -I../src -I../src/wave/common/../.. -Isrc/wave -I../src/wave/.. -isystem env/include -O3 -DNDEBUG -flto -fno-fat-lto-objects -include /home/mgodbolt/dev/wave/cmake-build-release/conda_env.hpp -fconcepts -Wall -Wextra -Werror -g -fPIC -fvisibility-inlines-hidden -march=skylake -Wconversion -Wsign-conversion -Wnon-virtual-dtor -Wold-style-cast -Wpedantic -Wuseless-cast -Wdouble-promotion -Wcast-align -Wduplicated-cond -Wlogical-op -Wrestrict -Wnull-dereference -pedantic -std=gnu++17 -MD -MT src/wave/common/CMakeFiles/wave_common.dir/App.cpp.o -MF src/wave/common/CMakeFiles/wave_common.dir/App.cpp.o.d -o src/wave/common/CMakeFiles/wave_common.dir/App.cpp.o -c ../src/wave/common/App.cpp ``` The attachments were created by putting -E at the end of the line, changing the `-o` location, then gzipping the output.
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #12 from Matt Godbolt --- Created attachment 51361 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51361=edit preprocessed. gzipped, Sentry.cpp
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #11 from Matt Godbolt --- Created attachment 51360 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51360=edit preprocessed, gzipped App.cpp
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #10 from Matt Godbolt --- Thanks! Will attach!
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #9 from Martin Liška --- (In reply to Michael Matz from comment #8) > (In reply to Martin Liška from comment #7) > > Hm, note the ccxjqZU1 file contains: > > > > libwave_common.a@0x4307c > > libwave_common.a@0x180314c > > > > What does the syntax mean? > > That's the syntax for 'the .o file found within the .a file at offset > 0x4307c'. Oh, thanks! > (.a files are very simple and contain .o files mostly verbatim with some > headers > and an index, so an offset within it is enough to describe a contained object > files (the sizes and such can be reconstructed from the object file header > itself)). Looking at the 2 offsets, we speak about App.cpp.o and Sentry.cpp.o. So we would need pre-processed source for these 2 files.
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #8 from Michael Matz --- (In reply to Martin Liška from comment #7) > Hm, note the ccxjqZU1 file contains: > > libwave_common.a@0x4307c > libwave_common.a@0x180314c > > What does the syntax mean? That's the syntax for 'the .o file found within the .a file at offset 0x4307c'. (.a files are very simple and contain .o files mostly verbatim with some headers and an index, so an offset within it is enough to describe a contained object files (the sizes and such can be reconstructed from the object file header itself)).
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #7 from Martin Liška --- Hm, note the ccxjqZU1 file contains: libwave_common.a@0x4307c libwave_common.a@0x180314c What does the syntax mean? I can reproduce it locally with: $ /dev/shm/objdir2/gcc/lto1 -quiet -fwpa libwave_common.a@0x4307c libwave_common.a@0x180314c -fltrans-output-list=gap_report.ltrans.out -O2 -fresolution=lm.res ... #0 0x01310aa2 in varpool_node::get_constructor (this=0x7639ab00) at /home/marxin/Programming/gcc2/gcc/varpool.c:302 #1 0x01c0e8f2 in ipa_icf::sem_variable::equals (this=0x2922fb0, item=0x2928940) at /home/marxin/Programming/gcc2/gcc/ipa-icf.c:1845 #2 0x01c119a5 in ipa_icf::sem_item_optimizer::subdivide_classes_by_equality (this=0x28fcc10, in_wpa=false) at /home/marxin/Programming/gcc2/gcc/ipa-icf.c:2817 #3 0x01c10cba in ipa_icf::sem_item_optimizer::execute (this=0x28fcc10) at /home/marxin/Programming/gcc2/gcc/ipa-icf.c:2578 #4 0x01c14620 in ipa_icf::ipa_icf_driver () at /home/marxin/Programming/gcc2/gcc/ipa-icf.c:3698 #5 0x01c162e1 in ipa_icf::pass_ipa_icf::execute (this=0x281a780) at /home/marxin/Programming/gcc2/gcc/ipa-icf.c:3745 #6 0x00dca608 in execute_one_pass (pass=0x281a780) at /home/marxin/Programming/gcc2/gcc/passes.c:2508 #7 0x00dcb490 in execute_ipa_pass_list (pass=0x281a780) at /home/marxin/Programming/gcc2/gcc/passes.c:2925 #8 0x0086a95c in do_whole_program_analysis () at /home/marxin/Programming/gcc2/gcc/lto/lto.c:3183 #9 0x0086add7 in lto_main () at /home/marxin/Programming/gcc2/gcc/lto/lto.c:3408 #10 0x00f1c482 in compile_file () at /home/marxin/Programming/gcc2/gcc/toplev.c:456 #11 0x00f1f08b in do_compile () at /home/marxin/Programming/gcc2/gcc/toplev.c:2205 #12 0x00f1f36e in toplev::main (this=0x7fffddfe, argc=8, argv=0x7fffdf08) at /home/marxin/Programming/gcc2/gcc/toplev.c:2340 #13 0x01cbd006 in main (argc=8, argv=0x7fffdf08) at /home/marxin/Programming/gcc2/gcc/main.c:39
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #6 from Martin Liška --- (In reply to Matt Godbolt from comment #4) > Interestingly, if we extract (with nm x) the files in the library, and glob > them in instead of naming the library file, everything works. We're having > difficulty constructing a reduced case, as we need a whole binary (including > all the libraries we use), else the link step fails with missing symbols > before it gets to the crash. What about "hacking" that with -shared -fPIC or so?
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #5 from Matt Godbolt --- > And can you please test a more recent compiler (gcc-10 or gcc-11)? Unfortunately not easily; we have a whole ecosystem of libraries we link in (not attached here). If we get any more time we'll try and update, but we've spent all the time debugging that we can afford for now. Sorry.
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #4 from Matt Godbolt --- Interestingly, if we extract (with nm x) the files in the library, and glob them in instead of naming the library file, everything works. We're having difficulty constructing a reduced case, as we need a whole binary (including all the libraries we use), else the link step fails with missing symbols before it gets to the crash.
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #3 from Martin Liška --- (In reply to Matt Godbolt from comment #2) > Hi Martin! > > Thanks for the quick reply. We don't have an easy way to do this in our > current setup: those files are built and published as a library by a > different system. We'll give it a go though. Thank you. And can you please test a more recent compiler (gcc-10 or gcc-11)?
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 --- Comment #2 from Matt Godbolt --- Hi Martin! Thanks for the quick reply. We don't have an easy way to do this in our current setup: those files are built and published as a library by a different system. We'll give it a go though.
[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING CC||marxin at gcc dot gnu.org Last reconfirmed||2021-08-25 --- Comment #1 from Martin Liška --- All right, I can take a look. But first, can you please reduce number of object files that cause the ICE: $ ar t libwave_common.a App.cpp.o Endpoint.cpp.o LineReader.cpp.o NodeMerger.cpp.o ParseTimestamp.cpp.o Price.cpp.o Sentry.cpp.o TempDirectory.cpp.o parse_byte_size.cpp.o Try providing *.o files directly on command line. And then, please create pre-processed files for the problematic objects. Plus, we'll need compilation arguments.
