[Bug lto/99898] Possible LTO object incompatibility on gcc-10 branch

[ohaiziejohwahkeezuoz at xff dot cz via Gcc-bugs]

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

--- Comment #1 from ohaiziejohwahkeezuoz at xff dot cz ---
I figured object files contain the version of the compiler, so the previous
version was GCC: (GNU) 10.2.1 20201110 (built from releases/gcc-10 at that
date)

[Bug lto/99898] New: Possible LTO object incompatibility on gcc-10 branch

[ohaiziejohwahkeezuoz at xff dot cz via Gcc-bugs]

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

Bug ID: 99898
   Summary: Possible LTO object incompatibility on gcc-10 branch
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ohaiziejohwahkeezuoz at xff dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I'm trying gcc (releases/gcc-10 branch with the last commit  Fri Oct 23
10:11:41 2020 +0200 - Fix up plugin header install)

And I'm seeing an ICE cross-compiling glib library when linking with 

i686-linux-musl-gcc  -o gio/gresource gio/gresource.p/gresource-tool.c.o
-L/workspace/megous.com/apps-c/static-deps/output/i686/sys/usr/lib
-Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -static -Wl,--start-group
gio/libgio-2.0.a glib/libglib-2.0.a gobject/libgobject-2.0.a
gmodule/libgmodule-2.0.a
/workspace/megous.com/apps-c/static-deps/output/i686/sys/usr/lib/libz.a
/workspace/megous.com/apps-c/static-deps/output/i686/sys/usr/lib/libmount.a
/workspace/megous.com/apps-c/static-deps/output/i686/sys/usr/lib/libblkid.a
-pthread -liconv -lm
/workspace/megous.com/apps-c/static-deps/output/i686/sys/usr/lib/libffi.a
-Wl,--end-group
lto1: internal compiler error: in lto_read_decls, at lto/lto-common.c:1956
Please submit a full bug report,
with preprocessed source if appropriate.

I'm compiling with fat LTO objects, and this only happens when mixing LTO
object files compiled with previous version of gcc on the tip of gcc-10 branch.
(and only with i686 target so far) Sorry I don't have precise version of the
previous compiler, but it was probably something close to 10.2 judging by the
dates on the object files.

Recompiling all dependencies with the same version of the compiler doesn't lead
to this ICE.

Maybe LTO version needs a bump prior to 10.3 release?

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #11 from ohaiziejohwahkeezuoz at xff dot cz ---
Try this:

touch a.a a.o
gcc -save-temps -Wl,-debug -o a a.o a.a -ldl

Outputs:

...

/usr/bin/ld -plugin /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/lto-wrapper
-plugin-opt=-fresolution=-ldl.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -pie -o a
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib/Scrt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/crtbeginS.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0
-L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../.. a.o a.a
-ldl -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state
--as-needed -lgcc_s --pop-state
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib/crtn.o
/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib/Scrt1.o: in
function `_start':
(.text+0x24): undefined reference to `main'


Notice the: ... -plugin-opt=-fresolution=-ldl.res ...

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #6 from ohaiziejohwahkeezuoz at xff dot cz ---
The ldlang.c:6868 assertion bug was fixed in binutils.

That leaves the -save-temps/gcc driver issue.

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #5 from ohaiziejohwahkeezuoz at xff dot cz ---
Since the assertion is in `ld`, I've also reported the issue with some new
details here https://sourceware.org/bugzilla/show_bug.cgi?id=24567

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #4 from ohaiziejohwahkeezuoz at xff dot cz ---
Without -save-temps, generated name is random. So while there's some issue
there, too, because '-ldl.res' doesn't make much sense as an output for %u.res,
it is not the cause of the assertion failure in ldlang.c:6868:

void
ldlang_add_file (lang_input_statement_type *entry)
{
  lang_statement_append (&file_chain,
 (lang_statement_union_type *) entry,
 &entry->next);

  /* The BFD linker needs to have a list of all input BFDs involved in
 a link.  */
  ASSERT (entry->the_bfd->link.next == NULL);  <- line 6868
  ASSERT (entry->the_bfd != link_info.output_bfd);


I've added this code prior to the asserts:

  info_msg ("A:%pI\n", entry);
  info_msg ("B:%pB\n", entry->the_bfd);
  if (entry->the_bfd->link.next)
info_msg ("C:%pB\n", entry->the_bfd->link.next);

This results in this output (I also have -Wl,--trace enabled here):

.snip

A:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/crtend.o
B:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/crtend.o
attempt to open
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/lib/crtn.o
succeeded
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/lib/crtn.o
A:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/lib/crtn.o
B:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/lib/crtn.o
apps/libapps.a
./libssl.a
./libcrypto.a
A:armcap.o
B:armcap.o (symbol from plugin)
C:a_bitstr.o (symbol from plugin)
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/bin/ld:
internal error
/workspace/megous.com/apps-c/static-deps/toolchains/sources/binutils-gdb/ld/ldlang.c
6873

That is, as soon as libcrypto.a starts being linked, ldlang_add_file() gets
called from here:

  /* We don't call ldlang_add_file for an archive.  Instead, the
 add_symbols entry point will call ldlang_add_file, via the
 add_archive_element callback, for each element of the archive
 which is used.  */
  switch (bfd_get_format (entry->the_bfd))
{
default:
  break;

case bfd_object:
  if (!entry->flags.reload)
ldlang_add_file (entry);
  break;

but it receives something it doesn't expect in entry->the_bfd->link.next.

[Bug driver/90392] [9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #3 from ohaiziejohwahkeezuoz at xff dot cz ---
Here it is:

${LDCMD:-aarch64-linux-musl-gcc} -pthread -Wa,--noexecstack -Wall -O3 -g0 -Os
-fomit-frame-pointer -Wno-implicit-fallthrough -flto -g0 -Os
-fomit-frame-pointer -Wno-implicit-fallthrough -flto -save-temps -L. 
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib
-Wl,--start-group -static -Wl,-debug \
-o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o
apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o
apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o
apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o
apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o
apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o
apps/req.o apps/rsa.o apps/rsautl.o apps/s_client.o apps/s_server.o
apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o apps/spkac.o apps/srp.o
apps/storeut
l.o apps/ts.o apps/verify.o apps/version.o apps/x509.o \
 apps/libapps.a -lssl -lcrypto -ldl -pthread

[Bug lto/90392] Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #1 from ohaiziejohwahkeezuoz at xff dot cz ---
Also, the issue did not happen with 8.3.0 and the same binutils. An I also get
this assertion when building with i686-musl-linux cross-compiler, but
interestingly, when building a differnt package (gnutls). -ffresolution=%u.res
expansion is also wrong in that case, though I'm not sure it's what causes the
assertion failure.

[Bug lto/90392] New: Assertion failure in ldlang.c:6868 when compiling with -flto

[ohaiziejohwahkeezuoz at xff dot cz]

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

Bug ID: 90392
   Summary: Assertion failure in ldlang.c:6868 when compiling with
-flto
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ohaiziejohwahkeezuoz at xff dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello,

I'm getting an assertion failure in ld when compiling with -flto.

The compiler is built with the exact same flags as in this bug:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89260

The assertion that fails is in ldlang.c:6868:

The only thing I've noticed that seems weird is that in gcc.c there is this
(notice -fresolution=%u.res):

#define LINK_PLUGIN_SPEC \
"%{" PLUGIN_COND": \
-plugin %(linker_plugin_file) \
-plugin-opt=%(lto_wrapper) \
-plugin-opt=-fresolution=%u.res \
%{flinker-output=*:-plugin-opt=-linker-output-known} \
%{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}}
\
}" PLUGIN_COND_CLOSE

But gcc produces this for me:

   -plugin-opt=-fresolution=-ldl.res

This seems intuitively wrong, and looks like some memory
corruption/mishandling.  %u should produce some randomly named temporary file,
instead it seems to generate output using some other part of the command line.
In this case it takes the value from the '-ldl' argument. The wrong value is
stable across multiple invocations.

It also causes issues in parallel builds because multiple parallel invocations
of gcc link step will overwrite and try to re-use the same -ldl.res file.


Full output of the compilation of openssl, where this hapens for me:

Convert string
'/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/9.0.1/:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib
exec/gcc/aarch64-linux-musl/9.0.1/:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-l
inux-musl/lib/gcc/aarch64-linux-musl/9.0.1/:/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/:/workspace/megous.com/apps-c/static-deps/toolchains/aarc
h64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/bin/'
into prefixes, separator = ':'
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/9.0.1/
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/9.0.1/
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/bin/
Convert string
'/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/bin:/bin'
into prefixes, separator = ':'
  - add prefix:
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/bin/
  - add prefix: /bin/ 
Looking for 'real-ld' 
Looking for 'collect-ld'  
Looking for 'ld'  
Looking for 'gnm' 
Looking for 'aarch64-linux-musl-gnm'  
Looking for 'nm'  
Looking for 'gstrip'  
Looking for 'aarch64-linux-musl-gstrip'   
Looking for 'strip'   
Looking for 'aarch64-linux-musl-gcc'  
Looking for 'aarch64-linux-musl-gcc'
collect2 version 9.0.1 20190430 (prerelease)
ld_file_name=
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-linux-musl/bin/ld
c_file_name =
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/bin/aarch64-linux-musl-gcc
nm_file_name=
/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib/gcc/aarch64-linux-musl/9.0.1/../../../../aarch64-l

[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #11 from ohaiziejohwahkeezuoz at xff dot cz ---
(In reply to Martin Liška from comment #8)
> I would like to get a reproducible test-case. You can run the linking
> command line with --save-temps --verbose. And then you can reduce number of
> objects needed. For .a files, one would need to extract them and provide .o
> files on command line. Doing that one can get minimal set of objects. And
> then you can create pre-processed files for these (-E option). It will
> generate a minimal reproducible test-case.

I don't know, the failing command has like 30kB of command line options after
doing what you suggest. It's huuuge for any kind of manual
processing/elimination.

[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #9 from ohaiziejohwahkeezuoz at xff dot cz ---
The build of harfbuzz 2.3.1 with gcc 8.2.0 succeeds.

I can also confirm that re-building all dependencies of harfbuzz with 8.2
branch rev268702 also succeeds.

So the issue is with 8.2.1 not being able to use/read LTO objects built with
8.2.0 in some specific cases (triggered by harfbuzz C++ code for me).

So if LTO object files are not supposed to be compatible between even minor gcc
releases, this can be closed.

[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #6 from ohaiziejohwahkeezuoz at xff dot cz ---
One question. Are the LTO object files built with gcc 8.2.0 supposed to be
compatible with those built with 8.2 branch tip? I have static library
dependencies that are also compiled with LTO, but with gcc 8.2.0.

Gcc doesn't complain about any version mismatch though.

[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #5 from ohaiziejohwahkeezuoz at xff dot cz ---
Reproducing this might be somewhat complicated, because harfbuzz has some
dependencies, which would also needed to be built. But I have captured the
failing command, and can run gdb on it interactively after segault, so if you
have any suggestions on what to look for, or how to extract more detail other
than the backtrace I've provided, I can do some debugging on my side.

It's failing at the final linking step (probably during the load/parsing of lto
object files from disk), where all the many object files are processed by the
LTO, so I can't provide the reduced testcase.

I'll check if harfbuzz 2.3.1 builds with gcc 8.2.0 (2.3.0 did, so that might
help in reducing the search space).

[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #4 from ohaiziejohwahkeezuoz at xff dot cz ---
See Comment 1 please.

CFLAGS for gcc are in Comment 2. Just "-ggdb -Og".

Failing cross-compiler is built on Arch Linux, with the default compiler:

# gcc --verbose

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC)

[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #2 from ohaiziejohwahkeezuoz at xff dot cz ---
The main problem is elsewhere (read_cgraph_and_symbols looks just like some
cascading assertion failure because of some other segfault). I recompiled gcc
with -Og -ggdb and managed to produce this backtrace:

Thread 6.1 "lto1-wpa" received signal SIGSEGV, Segmentation fault.
[Switching to process 20627]
0x0090c7ac in is_a_helper::test
(p=0x622e7365646f6e5f) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/cgraph.h:1953
1953  return p && p->type == SYMTAB_FUNCTION;
(gdb) bt
#0  0x0090c7ac in is_a_helper::test
(p=0x622e7365646f6e5f) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/cgraph.h:1953
#1  is_a (p=0x622e7365646f6e5f) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/is-a.h:187
#2  dyn_cast (p=0x622e7365646f6e5f) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/is-a.h:224
#3  input_node (file_data=file_data@entry=0x770ac000,
ib=ib@entry=0x19ca940, tag=LTO_symtab_unavail_node, nodes=nodes@entry=...)
at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/lto-cgraph.c:1253
#4  0x00910480 in input_cgraph_1
(file_data=file_data@entry=0x770ac000, ib=ib@entry=0x19ca940) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/lto-cgraph.c:1556
#5  0x00910a25 in input_symtab () at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/lto-cgraph.c:1864
#6  0x005f6962 in read_cgraph_and_symbols (nfiles=344,
fnames=0x1991aa0) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/lto/lto.c:2897
#7  0x005f6db8 in lto_main () at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/lto/lto.c:3362
#8  0x00a59b7a in compile_file () at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/toplev.c:455
#9  0x00a5bba7 in do_compile () at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/toplev.c:2132
#10 0x00a5c120 in toplev::main (this=this@entry=0x7fffd1e6,
argc=, argc@entry=29, argv=,
argv@entry=0x7fffd2e8)
at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/toplev.c:2267
#11 0x011c4c30 in main (argc=29, argv=0x7fffd2e8) at
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/gcc/main.c:39

(gdb) l
1948template <>
1949template <>
1950inline bool
1951is_a_helper ::test (symtab_node *p)
1952{
1953  return p && p->type == SYMTAB_FUNCTION;
1954}
1955
1956/* Report whether or not THIS symtab node is a vriable, aka
varpool_node.  */
1957
(gdb) p p
$1 = (symtab_node *) 0x622e7365646f6e5f
(gdb) p *p
Cannot access memory at address 0x622e7365646f6e5f


Looks like some memory corruption bug.

[Bug lto/89260] ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[ohaiziejohwahkeezuoz at xff dot cz]

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

--- Comment #1 from ohaiziejohwahkeezuoz at xff dot cz ---
./aarch64-linux-musl-gcc -v

Using built-in specs.
COLLECT_GCC=./aarch64-linux-musl-gcc
COLLECT_LTO_WRAPPER=/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/libexec/gcc/aarch64-linux-musl/8.2.1/lto-wrapper
Target: aarch64-linux-musl
Configured with:
/workspace/megous.com/apps-c/static-deps/toolchains/sources/gcc-8/configure
--target=aarch64-linux-musl
--prefix=/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl
--libdir=/workspace/megous.com/apps-c/static-deps/toolchains/aarch64-linux-musl/lib
--enable-languages=c,c++ --disable-werror --disable-nls --disable-multilib
--disable-shared --enable-tls --enable-threads=posix --disable-libmudflap
--disable-libsanitizer --disable-gnu-indirect-function --disable-libmpx
--enable-deterministic-archives --enable-libstdcxx-time
--enable-fully-dynamic-string --enable-cloog-backend=isl --enable-lto
--enable-libgomp --enable-checking=release
Thread model: posix
gcc version 8.2.1 20190208 (GCC) 

Harfbuzz CFLAGS/LDFLAGS:

  -g0 -Os -fomit-frame-pointer -flto

[Bug lto/89260] New: ICE in read_cgraph_and_symbols, at lto/lto.c:2800 while compiling harfbuzz

[ohaiziejohwahkeezuoz at xff dot cz]

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

Bug ID: 89260
   Summary: ICE in read_cgraph_and_symbols, at lto/lto.c:2800
while compiling harfbuzz
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ohaiziejohwahkeezuoz at xff dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-musl
 Build: x86_64-linux-unknown

Hello,

I get ICE with gcc 8.2.1 (trunk) rev268702.

gcc was built with:

configure \
--target=$TARGET \
--prefix="$PREFIX" \
--libdir="$PREFIX/lib" \
--enable-languages=$langs \
--disable-werror \
--disable-nls \
--disable-multilib \
--disable-shared \
--enable-tls \
--enable-threads=posix \
--disable-libmudflap \
--disable-libsanitizer \
--disable-gnu-indirect-function \
--disable-libmpx \
--enable-deterministic-archives \
--enable-libstdcxx-time \
--enable-fully-dynamic-string \
--enable-cloog-backend=isl \
--enable-lto \
--enable-libgomp \
--enable-checking=release \

I'm trying to build the upstream harfbuzz 2.3.1 package.

https://www.freedesktop.org/software/harfbuzz/release/

Sorry for not providing preprocessed file, but I'm not sure what to priovide,
given that lto build step fails. Hopefully it will be easily reproducible. Let
me know if I can provide more information.

/bin/sh ../libtool  --tag=CXX   --mode=link aarch64-linux-musl-g++  -fno-rtti
-g0 -Os -fomit-frame-pointer -flto -save-temps -fno-exceptions
-fno-threadsafe-statics -fvisibility-inlines-hidden 
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib -g0 -Os
-fomit-frame-pointer -flto -save-temps -static -all-static -o
hb-ot-shape-closure hb-ot-shape-closure.o options.o  ../src/libharfbuzz.la -lm
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib
-lglib-2.0 -pthread
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib/../lib64
-lffi  -L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib
-lfreetype
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib -lz
-lpng16 -lz   
libtool: link: aarch64-linux-musl-g++ -fno-rtti -g0 -Os -fomit-frame-pointer
-flto -save-temps -fno-exceptions -fno-threadsafe-statics
-fvisibility-inlines-hidden -g0 -Os -fomit-frame-pointer -flto -save-temps
-static -o hb-subset hb-subset.o options.o -pthread 
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib
../src/.libs/libharfbuzz.a
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib/../lib64
-lm ../src/.libs/libharfbuzz-subset.a
/workspace/megous.com/apps-c/static-deps/output/arm64-lto/builds/harfbuzz/src/harfbuzz-2.3.1/src/.libs/libharfbuzz.a
-lglib-2.0 -lffi -lfreetype -lpng16 -lz -pthread
libtool: link: aarch64-linux-musl-g++ -fno-rtti -g0 -Os -fomit-frame-pointer
-flto -save-temps -fno-exceptions -fno-threadsafe-statics
-fvisibility-inlines-hidden -g0 -Os -fomit-frame-pointer -flto -save-temps
-static -o hb-shape hb-shape.o options.o -pthread 
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib
../src/.libs/libharfbuzz.a
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib/../lib64
-lm -lglib-2.0 -lffi -lfreetype -lpng16 -lz -pthread
libtool: link: aarch64-linux-musl-g++ -fno-rtti -g0 -Os -fomit-frame-pointer
-flto -save-temps -fno-exceptions -fno-threadsafe-statics
-fvisibility-inlines-hidden -g0 -Os -fomit-frame-pointer -flto -save-temps
-static -o hb-view hb-view.o options.o ansi-print.o helper-cairo.o
helper-cairo-ansi.o view-cairo.o -pthread -pthread -pthread -pthread -pthread 
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib
../src/.libs/libharfbuzz.a
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib/../lib64
-lcairo -lgobject-2.0 -lglib-2.0 -lffi -lpixman-1 -lfontconfig -luuid -lxml2
-lm -lfreetype -lpng16 -lz -pthread
libtool: link: aarch64-linux-musl-g++ -fno-rtti -g0 -Os -fomit-frame-pointer
-flto -save-temps -fno-exceptions -fno-threadsafe-statics
-fvisibility-inlines-hidden -g0 -Os -fomit-frame-pointer -flto -save-temps
-static -o hb-ot-shape-closure hb-ot-shape-closure.o options.o -pthread 
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib
../src/.libs/libharfbuzz.a
-L/workspace/megous.com/apps-c/static-deps/output/arm64-lto/sys/usr/lib/../lib64
-lm -lglib-2.0 -lffi -lfreetype -lpng