[Bug c++/102067] New: SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[Bug c++/102067] New: SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

            Bug ID: 102067
           Summary: SEGFAULT in varpool_node::get_constructor during lto1
                    when optimising or not using debug symbols
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: matt at godbolt dot org
  Target Milestone: ---

Whillinking against a static library containing LTO objects, the `lto1` stage
crashes with a segfault during IPA/ICF:

```
#0  0x0000000000c8b1bb in varpool_node::get_constructor() ()
#1  0x00000000011cf80b in ipa_icf::sem_variable::equals(ipa_icf::sem_item*,
hash_map<symtab_node*, ipa_icf::sem_item*,
simple_hashmap_traits<default_hash_traits<symtab_node*>, ipa_icf::sem_item*>
>&) ()
#2  0x00000000011d1810 in
ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool) ()
#3  0x00000000011d9c35 in ipa_icf::sem_item_optimizer::execute() ()
#4  0x00000000011da9d7 in ipa_icf::pass_ipa_icf::execute(function*) ()
#5  0x000000000093e15a in execute_one_pass(opt_pass*) ()
#6  0x000000000093ef32 in execute_ipa_pass_list(opt_pass*) ()
```

The pointer returned by the call to `lto_get_function_in_decl_state` in
`get_constructor` is NULL, and it's dereferenced to cause the segfault.

We found that this only happens if optimization level 2 or greater is on and
debug symbols are not being generated. It seems something required is being
dropped by the optimizer (but kept if debug is on).

We were unable to reduce the situation beyond what is attached. The `repro.sh`
script reproduces the issue. We found the issue in 9.3, and the binaries in the
attachment were created by 9.3, but 9.4 also suffers from this issue.

The attachment is too large to put here, so I've uploaded here:
https://xania.org/media/gcc-lto-bug.tar.gz

This seems somewhat related to bug 87792; though it's hard to be sure it's the
same root cause.

[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

Martin Liška <marxin at gcc dot gnu.org> 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 <marxin at gcc dot gnu.org> ---
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.

[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #2 from Matt Godbolt <matt at godbolt dot org> ---
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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
(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

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #4 from Matt Godbolt <matt at godbolt dot org> ---
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

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #5 from Matt Godbolt <matt at godbolt dot org> ---
> 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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
(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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
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  0x0000000001310aa2 in varpool_node::get_constructor (this=0x7ffff639ab00)
at /home/marxin/Programming/gcc2/gcc/varpool.c:302
#1  0x0000000001c0e8f2 in ipa_icf::sem_variable::equals (this=0x2922fb0,
item=0x2928940) at /home/marxin/Programming/gcc2/gcc/ipa-icf.c:1845
#2  0x0000000001c119a5 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  0x0000000001c10cba in ipa_icf::sem_item_optimizer::execute (this=0x28fcc10)
at /home/marxin/Programming/gcc2/gcc/ipa-icf.c:2578
#4  0x0000000001c14620 in ipa_icf::ipa_icf_driver () at
/home/marxin/Programming/gcc2/gcc/ipa-icf.c:3698
#5  0x0000000001c162e1 in ipa_icf::pass_ipa_icf::execute (this=0x281a780) at
/home/marxin/Programming/gcc2/gcc/ipa-icf.c:3745
#6  0x0000000000dca608 in execute_one_pass (pass=0x281a780) at
/home/marxin/Programming/gcc2/gcc/passes.c:2508
#7  0x0000000000dcb490 in execute_ipa_pass_list (pass=0x281a780) at
/home/marxin/Programming/gcc2/gcc/passes.c:2925
#8  0x000000000086a95c in do_whole_program_analysis () at
/home/marxin/Programming/gcc2/gcc/lto/lto.c:3183
#9  0x000000000086add7 in lto_main () at
/home/marxin/Programming/gcc2/gcc/lto/lto.c:3408
#10 0x0000000000f1c482 in compile_file () at
/home/marxin/Programming/gcc2/gcc/toplev.c:456
#11 0x0000000000f1f08b in do_compile () at
/home/marxin/Programming/gcc2/gcc/toplev.c:2205
#12 0x0000000000f1f36e in toplev::main (this=0x7fffffffddfe, argc=8,
argv=0x7fffffffdf08) at /home/marxin/Programming/gcc2/gcc/toplev.c:2340
#13 0x0000000001cbd006 in main (argc=8, argv=0x7fffffffdf08) 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

[matz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

Michael Matz <matz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at gcc dot gnu.org

--- Comment #8 from Michael Matz <matz at gcc dot gnu.org> ---
(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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
(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

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #10 from Matt Godbolt <matt at godbolt dot org> ---
Thanks! Will attach!

[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #11 from Matt Godbolt <matt at godbolt dot org> ---
Created attachment 51360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51360&action=edit
preprocessed, gzipped App.cpp

[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #12 from Matt Godbolt <matt at godbolt dot org> ---
Created attachment 51361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51361&action=edit
preprocessed. gzipped, Sentry.cpp

[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #13 from Matt Godbolt <matt at godbolt dot org> ---
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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
(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

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #15 from Matt Godbolt <matt at godbolt dot org> ---
> 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++
-v    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
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/
LIBRARY_PATH=/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/:/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/:/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/lib/../lib/:/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/lib/../lib/:/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/usr/lib/../lib/:/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/lib/:/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/lib/:/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'src/binaries/gap_report/gap_report'
'-L/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/lib' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'

/envy/tradewinds/38/e526c9ac3dd516/bin/../libexec/gcc/x86_64-conda-linux-gnu/9.3.0/collect2
-plugin
/envy/tradewinds/38/e526c9ac3dd516/bin/../libexec/gcc/x86_64-conda-linux-gnu/9.3.0/liblto_plugin.so
-plugin-opt=/envy/tradewinds/38/e526c9ac3dd516/bin/../libexec/gcc/x86_64-conda-linux-gnu/9.3.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccXX2ZQe.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--sysroot=/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie
-o src/binaries/gap_report/gap_report
/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/usr/lib/../lib/Scrt1.o
/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/usr/lib/../lib/crti.o
/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtbeginS.o
-L/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/lib
-L/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0
-L/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc
-L/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/lib/../lib
-L/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/lib/../lib
-L/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/usr/lib/../lib
-L/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/lib
-L/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/lib
-L/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/usr/lib
-rpath /envy/tradewinds/38/e526c9ac3dd516/lib
src/binaries/gap_report/CMakeFiles/gap_report.dir/main.cpp.o -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 -lstdc++ -lm -lgcc_s -lgcc -lc
-lgcc_s -lgcc
/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtendS.o
/envy/tradewinds/38/e526c9ac3dd516/bin/../x86_64-conda-linux-gnu/sysroot/usr/lib/../lib/crtn.o
/envy/tradewinds/38/e526c9ac3dd516/bin/../libexec/gcc/x86_64-conda-linux-gnu/9.3.0/lto-wrapper
-fresolution=/tmp/ccXX2ZQe.res -flinker-output=pie
env/lib/libwave_common.a@0x4307c env/lib/libwave_common.a@0x180314c 
/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/bin/x86_64-conda_cos6-linux-gnu-g++
@/tmp/ccJMuHg7
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++
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) 
COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-O2' '-O2' '-v'
'-L/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/lib' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'src/binaries/gap_report/'
'-dumpbase' 'gap_report.wpa'
'-fltrans-output-list=/tmp/gap_report.Hio0Oc.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccXX2ZQe.res' '-flinker-output=pie' '-shared-libgcc'

/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/../../libexec/gcc/x86_64-conda-linux-gnu/9.3.0/lto1
-quiet -dumpdir src/binaries/gap_report/ -dumpbase gap_report.wpa
-mtune=generic -march=x86-64 -auxbase libwave_common -O2 -O2 -version
-fno-openmp -fno-openacc -fltrans-output-list=/tmp/gap_report.Hio0Oc.ltrans.out
-fwpa -fresolution=/tmp/ccXX2ZQe.res -flinker-output=pie @/tmp/cc6FOFfd
GNU GIMPLE (crosstool-NG 1.24.0.133_b0863d8_dirty) version 9.3.0
(x86_64-conda-linux-gnu)
        compiled by GNU C version 4.4.7 20120313 (Red Hat 4.4.7-23), GMP
version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU GIMPLE (crosstool-NG 1.24.0.133_b0863d8_dirty) version 9.3.0
(x86_64-conda-linux-gnu)
        compiled by GNU C version 4.4.7 20120313 (Red Hat 4.4.7-23), GMP
version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
during IPA pass: icf
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error:
/home/mgodbolt/dev/tradewinds/cmake-build-sanitize/env/bin/x86_64-conda_cos6-linux-gnu-g++
returned 1 exit status
compilation terminated.
/envy/tradewinds/38/e526c9ac3dd516/bin/../lib/gcc/x86_64-conda-linux-gnu/9.3.0/../../../../x86_64-conda-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
```

[Bug c++/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
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

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #17 from Matt Godbolt <matt at godbolt dot org> ---
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 ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=88220

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I wonder if this is fixed for GCC 10 by the patch which fixes PR 88220.

[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #19 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #18)
> I wonder if this is fixed for GCC 10 by the patch which fixes PR 88220.

This ICE is about variables for those we are unable loading a constructor.

[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #20 from Martin Liška <marxin at gcc dot gnu.org> ---
All right Matt, for now I would really recommend updating to gcc-11.
I think it should help.

[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #21 from Matt Godbolt <matt at godbolt dot org> ---
Thanks, I'd love to upgrade but in this instance I'm stuck on GCC 9.x until the
rest of my company can move to it. Nothing annoys me more than having to say
that, but ... at least we know what it is and that it's fixed in the future :)
This will help me make a case to upgrade!

[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[samuelpmish at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

Sam Mish <samuelpmish at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |samuelpmish at gmail dot com

--- Comment #22 from Sam Mish <samuelpmish at gmail dot com> ---
I'm hitting an issue similar to this in one of my projects:

gcc-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0


When linking with lto on a optimized build, gcc12 is crashing (apologies for
the long link line)

/usr/bin/g++-12 -Wall -Wextra  -pthread -save-temps     -Werror  -Wshadow
-Wdouble-promotion -Wconversion -Wundef -Wnull-dereference -Wold-style-cast 
-O3 -DNDEBUG -rdynamic    -fopenmp -Wl,-Bsymbolic-functions
src/serac/numerics/functional/tests/CMakeFiles/functional_qoi.dir/functional_qoi.cpp.o
-o tests/functional_qoi 
-Wl,-rpath,/home/sam/code/serac_libs_gcc12/gcc-12.1.0/lua-5.3.5-dquw3g42r65n5xisjxjm4qn77ztburb5/lib
 lib/libgtest_main.a  lib/libgtest.a  lib/libserac_state.a  lib/libserac_mesh.a
 lib/libserac_numerics.a  lib/libserac_infrastructure.a  lib/libaxom.a 
/home/sam/code/serac_libs_gcc12/gcc-12.1.0/umpire-2022.03.1-oh5f65jhr3zzxcaa52hbl5v6hokl7ukj/lib/libumpire.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/raja-2022.03.0-ssk34466yhhqwld7szsrmbc65e4c5257/lib/libRAJA.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/camp-2022.03.2-wb6wkruuotyvmioa4ngks4klpoiyxvp4/lib/libcamp.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/hdf5-1.8.21-izgwwdm7ola6qvpco4g5th4ywabgnysx/lib/libhdf5.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit_relay_mpi_io.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit_relay.a
 -lrt 
/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit_blueprint_mpi.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit_blueprint.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit_relay_mpi.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/conduit-0.8.4-upcl5uu5zbdtmgvtakiq3j3g7e52ilyu/lib/libconduit.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/lua-5.3.5-dquw3g42r65n5xisjxjm4qn77ztburb5/lib/liblua.so
 lib/libmfem.a  /usr/lib/gcc/x86_64-linux-gnu/12/libgomp.so 
/home/sam/code/serac_libs_gcc12/gcc-12.1.0/hypre-2.18.2-qjtod2f6fq6gs27xtac52qsogpaomxg5/lib/libHYPRE.a
 /usr/lib/x86_64-linux-gnu/libopenblas.so  -lm  -ldl 
/home/sam/code/serac_libs_gcc12/gcc-12.1.0/superlu-dist-6.1.1-dzfbn5o7xmj4afrbu5bobphtc6uo2cgl/lib/libsuperlu_dist.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/parmetis-4.0.3-basm6qwardrie3ty4shbelvyadmtes3j/lib/libparmetis.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/metis-5.1.0-srkgcb2bm5fwesct5zqa3y6h74jfwcf2/lib/libmetis.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_nvecserial.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_nvecparallel.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_nvecmpiplusx.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_cvodes.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_arkode.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/sundials-5.7.0-jdioj6objpqshembk7pcv32vohhzw2qv/lib/libsundials_kinsol.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/netcdf-c-4.7.4-ty2aqukbd6j7uuezhi7s42r7c7qqpynn/lib/libnetcdf.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/hdf5-1.8.21-izgwwdm7ola6qvpco4g5th4ywabgnysx/lib/libhdf5_hl.a

/home/sam/code/serac_libs_gcc12/gcc-12.1.0/hdf5-1.8.21-izgwwdm7ola6qvpco4g5th4ywabgnysx/lib/libhdf5.a
 -lm  -ldl 
/home/sam/code/serac_libs_gcc12/gcc-12.1.0/hdf5-1.8.21-izgwwdm7ola6qvpco4g5th4ywabgnysx/lib/libhdf5.a
 /usr/lib/x86_64-linux-gnu/libz.so  /usr/lib/x86_64-linux-gnu/libmpichcxx.so 
/usr/lib/x86_64-linux-gnu/libmpich.so && :
[build] during IPA pass: icf
[build] lto1: internal compiler error: Segmentation fault
[build] 0xb1f113 crash_signal
[build] ../../src/gcc/toplev.cc:322
[build] 0x7fe21814551f ???
[build] ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
[build] 0xdda228 varpool_node::get_constructor()
[build] ../../src/gcc/varpool.cc:300
[build] 0x17aea53 ipa_icf::sem_variable::equals(ipa_icf::sem_item*,
hash_map<symtab_node*, ipa_icf::sem_item*,
simple_hashmap_traits<default_hash_traits<symtab_node*>, ipa_icf::sem_item*>
>&)
[build] ../../src/gcc/ipa-icf.cc:1697
[build] 0x17afabe
ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool)
[build] ../../src/gcc/ipa-icf.cc:2732
[build] 0x17b7952 ipa_icf::sem_item_optimizer::execute()
[build] ../../src/gcc/ipa-icf.cc:2464
[build] 0x17b91ba ipa_icf_driver
[build] ../../src/gcc/ipa-icf.cc:3600
[build] 0x17b91ba ipa_icf::pass_ipa_icf::execute(function*)
[build] ../../src/gcc/ipa-icf.cc:364

[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #23 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Sam Mish from comment #22)
> I'm hitting an issue similar to this in one of my projects:
> 
> gcc-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
> 
> 
> When linking with lto on a optimized build, gcc12 is crashing (apologies for
> the long link line)
> 

Good! Can you please provide steps how to build the reproducer project?

[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[samuelpmish at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #24 from Sam Mish <samuelpmish at gmail dot com> ---
> Good! Can you please provide steps how to build the reproducer project?

Unfortunately, this project uses a large and unconventional build system, so
it's difficult to reproduce. I could upload the `.ii` files, but each of the
libraries in that /home/sam/code/serac_libs_gcc12/gcc-12.1.0/ directory were
built custom (and might be relevant to the failure)

I can look into trying to reproduce the issue in a docker image-- would that be
helpful?

[Bug ipa/102067] SEGFAULT in varpool_node::get_constructor during lto1 when optimising or not using debug symbols

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067

--- Comment #25 from Martin Liška <marxin at gcc dot gnu.org> ---
> I can look into trying to reproduce the issue in a docker image-- would that
> be helpful?

Yes.