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
