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

diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 3414ade..f93ff50 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -1010,7 +1010,7 @@ find_and_merge_options (int fd, off_t file_offset, const char *prefix,
       struct cl_decoded_option *f2decoded_options;
       unsigned int f2decoded_options_count;
       get_options_from_collect_gcc_options (collect_gcc,
-					    fopts, CL_LANG_ALL,
+					    fopts, CL_DRIVER,
 					    &f2decoded_options,
 					    &f2decoded_options_count);
       if (!fdecoded_options)
@@ -1283,7 +1283,7 @@ run_gcc (unsigned argc, char *argv[])
     fatal_error (input_location,
 		 "environment variable %<COLLECT_GCC_OPTIONS%> must be set");
   get_options_from_collect_gcc_options (collect_gcc, collect_gcc_options,
-					CL_LANG_ALL,
+					CL_DRIVER,
 					&decoded_options,
 					&decoded_options_count);
 

Reply via email to