This is the mail archive of the
mailing list for the GCC project.
Re: PR driver/91130 Use CL_DRIVER when handling of COLLECT_GCC_OPTIONS in lto-wrapper.c
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Richard Biener <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 7 Aug 2019 17:08:28 +0100
- Subject: Re: PR driver/91130 Use CL_DRIVER when handling of COLLECT_GCC_OPTIONS in lto-wrapper.c
- References: <email@example.com> <20190807135142.GF2726@tucnak>
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.
* lto-wrapper.c (find_and_merge_options): Use CL_DRIVER when
Bootstrapped on aarch64-linux
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. */
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.
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.