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.

Reply via email to