[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

["prathamesh3492 at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
(In reply to clyon from comment #16)
> (In reply to prathamesh3492 from comment #15)
> 
> > I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> > run_gcc().
> Isn't this because you configured GCC --with-fpu=vfpv3-d16?

COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
/* Build COLLECT_GCC_OPTIONS to have all of the options specified to
     the compiler.  */
  obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
                sizeof ("COLLECT_GCC_OPTIONS=") - 1);

and at the end of set_collect_gcc_options():
xputenv (XOBFINISH (&collect_obstack, char *));
which makes it environment variable.

set_collect_gcc_options() is called by do_spec, which is called by
driver::maybe_run_linker(), before executing linker.
So the driver has no knowledge of options passed at compile-time,
it sets the default -mfpu=vfpv3-d16.

When lto-wrapper executes,
it gets linker command line options from environment variable
COLLECT_GCC_OPTIONS,
which contains -mfpu=vfpv3-d16.
and since that was being appended after compile-time options
(fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.

This also explains why it works in one shot
arm-linux-gnueabihf -flto -mfpu=neon test.c

COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.

When compiler and linker are run separately, at link time, the driver has no
knowledege of flags of compile-time run,
and hence sets default flags in COLLECT_GCC_OPTIONS.

I think correct way to fix would be in run_gcc() to get values from
COLLECT_GCC_OPTIONS in decoded_options as is currently done.
run_gcc() walks through options in object file and saves it in
fdecoded_options. So override the value in
decoded_options for the same option found in fdecoded_options. 
Would that be a right approach ?

Thank you,
Prathamesh