On 07/08/2019 14:51, Jakub Jelinek wrote:
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
Ok, I'll do that. Do you want it on the gcc-9 branch as well? I'm
running a bootstrap of it right now.
R.
