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
