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

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:

> 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 ?

No, link-time options always override compile-time ones.

I suspect the fix will be to somehow avoid setting defaults when linking?