https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #27 from Matt Breedlove <breedlove.matt at gmail dot com> --- The primary differences between the 4.9 branch and 5.1.0 are only that the underlying issue now results in a fatal error. In the 4.9 branch, the objects and archives (even "-fresolution=libarchive.res" verbatim) are opened to see whether they exist and if so, then are parsed for LTO options. In 4.9, if they fail to be opened as files *or* if they fail have parse-able LTO section, they are still passed along the command-line. Currently in 5.1.0 (without patches listed here), if a file does not exist (such as an archive with an offset since argv[i] is used) then it is not parsed for LTO sections and passed along as-in. If an object is found, then it is parsed for LTO sections and passed along only if it has those sections. The real question is what behavior should be given if a non-LTO object is passed along with an LTO build. This wasn't a problem before because in 4.9 and prior, even when it failed to parse LTO sections for that file, the file would still be passed along on the command-line. With the current functionality, I believe failing to parse the file and failing to find LTO sections within the file are essentially equivalent in which case the file is not passed along any longer. The problem with Richard's patch seems opposite to me. Since lto_argv is used as a container to hold the objects/archives that are passed along into the output, these should likely contain all objects/archives whether they have LTO options with them or not or the result is that we're simply dropping objects. The reason that there weren't failures on archive files previously is precisely because we are adding files that do not exist explicitly to that array when we fail to open them which has hidden the underlying issue in previous versions. The lines below show how these objects are being added to the output: /* Append the input objects and possible preceding arguments. */ for (i = 0; i < lto_argc; ++i) obstack_ptr_grow (&argv_obstack, lto_argv[i]); Where do the objects that don't have LTO sections go? Nowhere. These issues are present in previous versions but went unnoticed for the only reason that there was no temporary lto_argv array.