Bug 66687 - WPA link fau: internal compiler error: bytecode stream: found non-null terminated string
Summary: WPA link fau: internal compiler error: bytecode stream: found non-null termin...
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, lto
Depends on:
Blocks:
 
Reported: 2015-06-27 00:41 UTC by Guido Haztsis
Modified: 2021-12-24 11:02 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
res file (311 bytes, application/x-dtbresource+xml)
2015-06-27 00:41 UTC, Guido Haztsis
Details
preproc source (80 bytes, text/plain)
2015-06-27 00:42 UTC, Guido Haztsis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guido Haztsis 2015-06-27 00:41:58 UTC
Created attachment 35860 [details]
res file

With gcc 5.1 is was possible to compile executables statically with with an libc (musl) static library. It is no longer possible with 6.0



COLLECT_GCC_OPTIONS='-c' '-ffp-contract=off' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math' '-fno-trapv' '-fno-openmp' '-fno-openacc' '-mtune=generic' '-march=x86-64' '-O2' '-fPIC' '-fno-exceptions' '-B' '/x32/gcc/stageN/./gcc/' '-B' '/x32/build/host/x86_64-sb-linux-muslx32/bin/' '-B' '/x32/build/host/x86_64-sb-linux-muslx32/lib/' '-v' '-save-temps' '-mtune=generic' '-march=x86-64' '-fltrans-output-list=/tmp/cctXDCnL.ltrans.out' '-fwpa' '-fresolution=conftest.res'
 /x32/gcc/stageN/./gcc/lto1 -quiet -dumpbase crt1.o -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase crt1 -O2 -version -ffp-contract=off -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv -fno-openmp -fno-openacc -fPIC -fno-exceptions -fltrans-output-list=/tmp/cctXDCnL.ltrans.out -fwpa -fresolution=conftest.res @/tmp/ccir6VzL

GNU GIMPLE (GCC) version 6.0.0 20150619 (experimental) (x86_64-sb-linux-muslx32)
	compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 6.0.0 20150619 (experimental) (x86_64-sb-linux-muslx32)
	compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version 3.1.3, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
lto1: internal compiler error: bytecode stream: found non-null terminated string
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: /x32/gcc/stageN/./gcc/xgcc returned 1 exit status
compilation terminated.
[Leaving LTRANS /tmp/ccO8tBym]
[Leaving LTRANS /tmp/cctXDCnL.ltrans.out]
/x32/build/host/x86_64-sb-linux-muslx32/bin/ld: fatal error: lto-wrapper failed
Comment 1 Guido Haztsis 2015-06-27 00:42:20 UTC
Created attachment 35861 [details]
preproc source
Comment 2 Andrew Pinski 2015-06-27 00:45:32 UTC
Are you sure that this is not a bug in musl?
Comment 3 Guido Haztsis 2015-06-27 01:16:05 UTC
Musl claims that they support LTO. Also all that I have changed was bumping gcc from the 5.1_release tag to the latest overnight commit.

The res file doesn't even include libc.so (nor libc.a for a static build) which is strange and musl has long claimed to support lto without fat objects.

(In reply to Andrew Pinski from comment #2)
> Are you sure that this is not a bug in musl?
Comment 4 Andrew Pinski 2015-06-27 01:24:06 UTC
MUSL support is not included in GCC 5.x is another thing.  Also you are using x32 which is not tested that much.
Comment 5 H.J. Lu 2015-06-27 15:15:31 UTC
(In reply to Andrew Pinski from comment #4)
> MUSL support is not included in GCC 5.x is another thing.  Also you are
> using x32 which is not tested that much.

Can it be reproduced with x32 glibc?
Comment 6 Guido Haztsis 2015-06-28 19:50:25 UTC
(In reply to H.J. Lu from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > MUSL support is not included in GCC 5.x is another thing.  Also you are
> > using x32 which is not tested that much.
> 
> Can it be reproduced with x32 glibc?

I am pretty sure it can be reproduced without any libc. Actually, for some reason the libc.a file isn't even in the res file. This used to appear in the 5.1 version.
Comment 7 H.J. Lu 2015-06-28 19:57:07 UTC
(In reply to Guido Haztsis from comment #6)
> I am pretty sure it can be reproduced without any libc. Actually, for some
> reason the libc.a file isn't even in the res file. This used to appear in
> the 5.1 version.

Does it mean it is musl specific and it can be reproduced with
musl for any targets?
Comment 8 Andrew Pinski 2015-06-29 04:34:57 UTC
(In reply to Guido Haztsis from comment #6)
> (In reply to H.J. Lu from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > MUSL support is not included in GCC 5.x is another thing.  Also you are
> > > using x32 which is not tested that much.
> > 
> > Can it be reproduced with x32 glibc?
> 
> I am pretty sure it can be reproduced without any libc. Actually, for some
> reason the libc.a file isn't even in the res file. This used to appear in
> the 5.1 version.

We are talking about the compiled GCC here.  Not the one being used with GCC at this point.
Comment 9 Richard Biener 2015-06-29 08:42:52 UTC
Are you sure you produced all LTO bytecode with exactly the same compiler?
Reminds me to bump the LTO bytecode version again on trunk (it's still the same
as that on the GCC 5 branch...)
Comment 10 Guido Haztsis 2015-07-01 23:32:12 UTC
(In reply to Richard Biener from comment #9)
> Are you sure you produced all LTO bytecode with exactly the same compiler?
> Reminds me to bump the LTO bytecode version again on trunk (it's still the
> same
> as that on the GCC 5 branch...)

Was it bumped from 4 to 5? Yes, I am pretty sure I am using the same compliler.