5.1.0/4.9.2 native mingw64 lto-wrapper.exe issues (PR 65559 and 65582)
I was told I should repost this on this ML rather than the gcc-help list I originally posted this under. Here was my original thread: https://gcc.gnu.org/ml/gcc-help/2015-04/msg00167.html 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
5.1.0 / 5.1.1 mingw64 bootstrap LTO failure questions
I've posted an update to PR 66014 regarding mingw64 slim LTO bootstrap errors I had been getting I was hoping to get some comments on. Though this resolves the problem for me, I'm wondering what other potential issues similar to it may spring up and was hoping to get some feedback. In addition, there is another related failure when doing bootstrap-lto or bootstrap-lto-noplugin (slim or fat) in mingw64 relating to sys_siglist. mingw64 (as far as I know) does not have an implementation for it. The issue is as follows: 1. stage1 completes bootstrapping. strsignal and sys_siglist are undetected resulting in HAVE_STRSIGNAL and HAVE_SYS_SIGLIST. 2. stage2 (or stagefeedback) detects strsignal but not sys_siglist leaving HAVE_SYS_SIGLIST defined. This causes libiberty to define strsignal but skips sys_siglist during the build leaving an undefined reference to sys_siglist. 3. Build fails when attempting to link against the new LTO libiberty.a(strsignal.o) when building gcc-nm, gcc-ar, etc. Non-LTO builds suffer neither problem and fat bootstraps only suffer from the issue above which I have worked around by passing in "libiberty_cv_var_sys_siglist=no" during configuration. Combined with building libiberty with "-fno-builtin-stpcpy" (PR 66014), I have gotten all builds to finally succeed. I could use some guidance on where to go from here, however. Thanks, Matt
