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

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

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

--- Comment #15 from prathamesh3492 at gcc dot gnu.org ---
Hi,
I am not entirely sure, the issue seems to be in lto-wrapper.
In lto-wrapper.c:run_gcc():
fdecoded_options, which are compiler options contains "-mfpu=neon"
decoded_options, which are linker options contains "-mfpu=vfpv3-d16".
decoded_options are populated by 
lto-wrapper.c:get_options_from_collect_gcc_options() from environment
variable COLLECT_GCC_OPTIONS.

fdecoded_options are appended after decoded_options in run_gcc():

  append_linker_options (&argv_obstack, decoded_options,
decoded_options_count);
  append_compiler_options (&argv_obstack, fdecoded_options,
                           fdecoded_options_count);

which is why -mfpu=vfpv3-d16 overrides -mfpu=neon.

Reversing the order of above function calls works fine for me
for the above test-case.

However I am not sure if this is the right approach,
It now passes -mfpu=vfpv3-d16 and then it's overriden by -mfpu=neon
since we reversed the order.
Ideally we don't want -mfpu=vfpv3-d16 to appear ?

I am not understanding why vfpv3-d16 appears in collect_gcc_options in
run_gcc().
While writing COLLECT_GCC_OPTIONS in
lto-opts.c:append_to_collect_gcc_options(), -mfpu=vfpv3-d16 is not present,
Only -mfpu=neon is present, which is correct since it was passed as a command
line option.

I am not sure what modifies COLLECT_GCC_OPTIONS before it is read by run_gcc()
in lto-wrapper.

Thank you,
Prathamesh