This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR driver/91130 Use CL_DRIVER when handling of COLLECT_GCC_OPTIONS in lto-wrapper.c

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
	(run_gcc): Likewise.

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.  */
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.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]