5.1.0/4.9.2 native mingw64 lto-wrapper.exe issues (PR 65559 and 65582)

[Matt Breedlove <breedlove dot matt at gmail dot com>]

I came across PR 65559 and 65582 while investigating why I was getting
the "lto1.exe: internal compiler error: in read_cgraph_and_symbols, at
lto/lto.c:2947" error during a native MINGW64 LTO build.  This also
seems to be present when enabling bootstrap-lto within 5.1.0
presenting an error message akin to what is listed in PR 65582.

1.

Under:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/lto-wrapper.c;h=404cb68e0d1f800628ff69b7672385b88450a3d5;hb=HEAD#l927

lto-wrapper processes command-line params for filenames match (in my
case) "./.libs/libspeexdsp.a@0x44e26" and separates the filename from
the offset into separate variables.  Since the following check to see
if that file exists by opening it doesn't use the parsed filename
variable and instead continues to use the argv parameter, the attempt
to open it always fails and that file is not specifically parsed for
LTO options.


2.

One other issue I've noticed in my build happens as a result of the
open call when trying to parse the options using libiberty.  Under
mingw64 native, the open call opens the object file in text mode and
then passes the fd eventually to libiberty's
simple_object_internal_read within simple-object.c.  The issue springs
up trying to perform a read and it hits a CTRL+Z (0x1A) within the
object at which point the next read will return 0 bytes and trigger
the break of the loop and a subsequent error message of "file too
short" which gets silently ignored.  In my testing, changing the 0x1A
within the object file to something else returns the full read (or
more data until another CTRL+Z is hit).

Ref: https://msdn.microsoft.com/en-us/library/wyssk1bs.aspx

This still happens within 4.9.2 and 4.9 trunk however in 4.9, the
object file being checked for LTO sections is still passed along in
the command-line whereas in 5.1.0 it gets skipped but is still listed
within the res file most likely leading to the ICE within 65559.  This
would also explain Kai's comment on why this issue only occurs on
native builds.  The ICE in 5.1.0 can also be avoided by using an
lto-wrapper from 4.9 or prior allowing the link to complete though no
LTO options will get processed due to #1.


This is my first report so I wouldn't mind some guidance.  I'm
familiar enough with debugging to gather whatever other level details
are requested.  Most of this was found using gdb.

--
Matt Breedlove