On Wed, Aug 07, 2019 at 01:42:34PM +0100, Richard Earnshaw (lists) wrote:
> Some options are handled differently by the main driver (gcc, g++, etc) from
> the back-end compiler programs (cc1, cc1plus, etc) in that in the driver
> they do not take an additional argument, while in the compiler programs they
> do. The processing option option CL_DRIVER controls this alternative
> interpretation of the options.
>
> The environment variable COLLECT_GCC_OPTIONS is the list of options to add
> to a compile if the compiler re-invokes itself at some point. As such, the
> options are driver options, so CL_DRIVER should be used when processing this
> list. Currently lto-wrapper is doing this incorrectly.
>
> PR driver/91130
> * lto-wrapper.c (find_and_merge_options): Use CL_DRIVER when
> processing COLLECT_GCC_OPTIONS.
> (run_gcc): Likewise.
>
> Bootstrapped on aarch64-linux
>
> OK?
>
> NB, this is essentially the same as Richi's patch in the PR. I'll let you
> decide which to take...
I think I'd prefer the patch Richi pasted with the
--- gcc/lto-wrapper.c 2019-08-07 14:36:30.781562354 +0200
+++ gcc/lto-wrapper.c 2019-08-07 15:48:55.140279384 +0200
@@ -128,7 +128,7 @@ maybe_unlink (const char *file)
#define DUMPBASE_SUFFIX ".ltrans18446744073709551615"
/* Create decoded options from the COLLECT_GCC and COLLECT_GCC_OPTIONS
- environment according to LANG_MASK. */
+ environment. */
static void
get_options_from_collect_gcc_options (const char *collect_gcc,
incremental change, because it really doesn't make sense to pass to
get_options_from_collect_gcc_options the same constant value in both
invocations (well, it didn't make sense before either).
Though, I'm fine if you commit your patch now as a fix and Richi's patch
with the above incremental change is applied on top of it incrementally
as a cleanup.
Jakub
