Support multilib-aware target lib flags self-specs overriding

This patch introduces -multiflags, short for multilib TFLAGS, as an
option that does nothing by default, but that can be added to TFLAGS
and mapped to useful options by driver self-specs.

I realize -m is reserved for machine-specific flags, which this option
sort-of isn't, but its intended use is indeed to stand for
machine-specific flags, so it's kind of ok.  But that's just my
official excuse, the reason I couldn't help picking it up is that it
is a portmanteau of multi[lib] and TFLAGS.

Regstrapped on x86_64-linux-gnu.  Ok to install?


<aside>

Also tested with cross compilers configured to fail when missing
-multiflags, as suggested in the last paragraph in the added docs.

Tests to flag uses of the just-built compiler without -multiflags
required various workarounds.  Self-tests in GCC are compiled without
TFLAGS, so they'd fail if it weren't for a separate patchlet I'm
undecided about.  TFLAGS aren't used by gnattools or gotools either,
even when they are built with *_FOR_TARGET compilers, namely in native
builds, so those fail the above.  Another issue comes up when
bootstrapping: stages other than 1 use a just-built compiler to compile
for the target, in a way, but they don't use TFLAGS.

This brings about the philosophical/practical question of whether TFLAGS
is to apply to target libraries only, or to all compilations using the
just-built compiler, even those for host=target.  I can think of
arguments to support either choice.

I have changes that add TFLAGS for GCC self-tests, gnattools and gotools
(but not for bootstrap stages), and I'd be happy to proceed with them,
but I'd like to hear about any concerns or potential use cases for the
alternatives before proceeding with these changes.

Other possibilities that occurred to me were add a THFLAGS to the
top-level for host components that, in native builds, build with a
for-the-target just-built compiler (gnattools and gotools), or even get
the top level to pass <compiler>_FOR_TARGET along with TFLAGS or THFLAGS
down as <compiler> to such host tools (and that or the previous stage's
TFLAGS when using the previous stage's compiler during bootstraps), like
it adds TFLAGS to <compiler> for target libs.

</aside>


for  gcc/ChangeLog

	* common.opt (multiflags): New.
	* doc/invoke.texi: Document it.
	* gcc.cc (driver_self_specs): Discard it.
	* opts.cc (common_handle_option): Ignore it in the driver.
---
 gcc/common.opt      |    4 ++++
 gcc/doc/invoke.texi |   30 +++++++++++++++++++++++++++++-
 gcc/gcc.cc          |    6 +++++-
 gcc/opts.cc         |    4 ++++
 4 files changed, 42 insertions(+), 2 deletions(-)

On May 20, 2022, Alexandre Oliva <oliva@adacore.com> wrote:

> Regstrapped on x86_64-linux-gnu.  Ok to install?

Ping?  https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595356.html

> for  gcc/ChangeLog

> 	* common.opt (multiflags): New.
> 	* doc/invoke.texi: Document it.
> 	* gcc.cc (driver_self_specs): Discard it.
> 	* opts.cc (common_handle_option): Ignore it in the driver.

On Fri, 20 May 2022, Alexandre Oliva via Gcc-patches wrote:
>
> This patch introduces -multiflags, short for multilib TFLAGS, as an
> option that does nothing by default, but that can be added to TFLAGS
> and mapped to useful options by driver self-specs.
>
> I realize -m is reserved for machine-specific flags, which this option
> sort-of isn't, but its intended use is indeed to stand for
> machine-specific flags, so it's kind of ok.  But that's just my
> official excuse, the reason I couldn't help picking it up is that it
> is a portmanteau of multi[lib] and TFLAGS.

Ooh, a bikeshedding opportunity!
Not liking the "-m"-space infringement:

-frob-multiflags?
-forward-multiflags?
or why not just
-fmultiflags?

brgds, H-P

On Jun  1, 2022, Hans-Peter Nilsson <hp@bitrange.com> wrote:

> On Fri, 20 May 2022, Alexandre Oliva via Gcc-patches wrote:
>> 
>> This patch introduces -multiflags, short for multilib TFLAGS, as an
>> option that does nothing by default, but that can be added to TFLAGS
>> and mapped to useful options by driver self-specs.
>> 
>> I realize -m is reserved for machine-specific flags, which this option
>> sort-of isn't, but its intended use is indeed to stand for
>> machine-specific flags, so it's kind of ok.  But that's just my
>> official excuse, the reason I couldn't help picking it up is that it
>> is a portmanteau of multi[lib] and TFLAGS.

> Ooh, a bikeshedding opportunity!

:-)

> Not liking the "-m"-space infringement:

:-(

> -fmultiflags?

That works for me.  I favored -multiflags slightly, because the intended
use is for it to stand for other -m flags, but --multiflags AKA
-fmultiflags will do as well.


Now, is there interest in this feature?  (As in, does it any make sense
for me to post a revised patch, or should I keep it downstream?)

On Jun  3, 2022, Alexandre Oliva <oliva@adacore.com> wrote:

> On Jun  1, 2022, Hans-Peter Nilsson <hp@bitrange.com> wrote:

>> -fmultiflags?

> That works for me.  I favored -multiflags slightly, because the intended
> use is for it to stand for other -m flags, but --multiflags AKA
> -fmultiflags will do as well.


> Now, is there interest in this feature?  (As in, does it any make sense
> for me to post a revised patch, or should I keep it downstream?)

FTR, here's the patch I ended up with, adjusted to use -fmultiflags.


Support multilib-aware target lib flags self-specs overriding

This patch introduces -fmultiflags, short for multilib TFLAGS, as an
option that does nothing by default, but that can be added to TFLAGS
and mapped to useful options by driver self-specs.

Regstrapped on x86_64-linux-gnu.  Posted mainly FTR, but...  I wouldn't
mind putting it in, so...  Ok to install?  ;-)


for  gcc/ChangeLog

	* common.opt (fmultiflags): New.
	* doc/invoke.texi: Document it.
	* gcc.cc (driver_self_specs): Discard it.
	* opts.cc (common_handle_option): Ignore it in the driver.
---
 gcc/common.opt      |    4 ++++
 gcc/doc/invoke.texi |   30 +++++++++++++++++++++++++++++-
 gcc/gcc.cc          |    6 +++++-
 gcc/opts.cc         |    4 ++++
 4 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index e7a51e882bade..814966c4562fe 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2177,6 +2177,10 @@ fmove-loop-stores
 Common Var(flag_move_loop_stores) Optimization
 Move stores out of loops.
 
+fmultiflags
+Common Driver
+Building block for specs-based multilib-aware TFLAGS.
+
 fdce
 Common Var(flag_dce) Init(1) Optimization
 Use the RTL dead code elimination pass.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index bde59ff047249..f9c53df37b28b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -725,7 +725,7 @@ Objective-C and Objective-C++ Dialects}.
 -flto-report  -flto-report-wpa  -fmem-report-wpa @gol
 -fmem-report  -fpre-ipa-mem-report  -fpost-ipa-mem-report @gol
 -fopt-info  -fopt-info-@var{options}@r{[}=@var{file}@r{]} @gol
--fprofile-report @gol
+-fmultiflags  -fprofile-report @gol
 -frandom-seed=@var{string}  -fsched-verbose=@var{n} @gol
 -fsel-sched-verbose  -fsel-sched-dump-cfg  -fsel-sched-pipelining-verbose @gol
 -fstats  -fstack-usage  -ftime-report  -ftime-report-details @gol
@@ -18927,6 +18927,34 @@ allocation for the WPA phase only.
 Makes the compiler print some statistics about permanent memory
 allocation before or after interprocedural optimization.
 
+@item -fmultiflags
+@opindex fmultiflags
+This option enables multilib-aware @code{TFLAGS} to be used to build
+target libraries with options different from those the compiler is
+configured to use by default, through the use of specs (@xref{Spec
+Files}) set up by compiler internals, by the target, or by builders at
+configure time.
+
+Like @code{TFLAGS}, this allows the target libraries to be built for
+portable baseline environments, while the compiler defaults to more
+demanding ones.  That's useful because users can easily override the
+defaults the compiler is configured to use to build their own programs,
+if the defaults are not ideal for their target environment, whereas
+rebuilding the runtime libraries is usually not as easy or desirable.
+
+Unlike @code{TFLAGS}, the use of specs enables different flags to be
+selected for different multilibs.  The way to accomplish that is to
+build with @samp{make TFLAGS=-fmultiflags}, after configuring
+@samp{--with-specs=%@{fmultiflags:...@}}.
+
+This option is discarded by the driver once it's done processing driver
+self spec.
+
+It is also useful to check that @code{TFLAGS} are being used to build
+all target libraries, by configuring a non-bootstrap compiler
+@samp{--with-specs='%@{!fmultiflags:%emissing TFLAGS@}'} and building
+the compiler and target libraries.
+
 @item -fprofile-report
 @opindex fprofile-report
 Makes the compiler print some statistics about consistency of the
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 5cbb38560b266..24d3544e68140 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -1347,7 +1347,11 @@ static const char *const multilib_defaults_raw[] = MULTILIB_DEFAULTS;
 
 static const char *const driver_self_specs[] = {
   "%{fdump-final-insns:-fdump-final-insns=.} %<fdump-final-insns",
-  DRIVER_SELF_SPECS, CONFIGURE_SPECS, GOMP_SELF_SPECS, GTM_SELF_SPECS
+  DRIVER_SELF_SPECS, CONFIGURE_SPECS, GOMP_SELF_SPECS, GTM_SELF_SPECS,
+  /* This discards -fmultiflags at the end of self specs processing in the
+     driver, so that it is effectively Ignored, without actually marking it as
+     Ignored, which would get it discarded before self specs could remap it.  */
+  "%<fmultiflags"
 };
 
 #ifndef OPTION_DEFAULT_SPECS
diff --git a/gcc/opts.cc b/gcc/opts.cc
index fe0293e4283df..1ac9554a341c6 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -3257,6 +3257,10 @@ common_handle_option (struct gcc_options *opts,
       dc->report_bug = value;
       break;
 
+    case OPT_fmultiflags:
+      gcc_checking_assert (lang_mask == CL_DRIVER);
+      break;
+
     default:
       /* If the flag was handled in a standard way, assume the lack of
 	 processing here is intentional.  */

On Jun 28, 2022, Alexandre Oliva <oliva@adacore.com> wrote:

> Support multilib-aware target lib flags self-specs overriding

> This patch introduces -fmultiflags, short for multilib TFLAGS, as an
> option that does nothing by default, but that can be added to TFLAGS
> and mapped to useful options by driver self-specs.

> Regstrapped on x86_64-linux-gnu.  Posted mainly FTR, but...  I wouldn't
> mind putting it in, so...  Ok to install?  ;-)

Since this patch didn't seem to gain much traction towards acceptance,
I've been thinking of other ways to accomplish its goal, namely, to
enable target libs to be built with additional flags, like setting
TFLAGS, but enabling different multilibs to be built with different
flags.

The other way that came to mind was to add settings to the multilib
target fragment configurations, say MULTILIB_TFLAGS, to map multilibs to
extra flags to use, and then adjust the target lib multilib flag build
machinery to extract and add these flags when configuring and building
each library.  Yuck.

I'd much rather we could use -fmultiflags, a far more elegant
arrangement IMHO, so...

Ping?  https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597419.html

> for  gcc/ChangeLog

> 	* common.opt (fmultiflags): New.
> 	* doc/invoke.texi: Document it.
> 	* gcc.cc (driver_self_specs): Discard it.
> 	* opts.cc (common_handle_option): Ignore it in the driver.


Since this is kind of a build machinery feature, would anyone mind if I
self-approved this with my build machinery maintainer hat on?

Please raise your objection within one week if you do.

Thanks,

On Oct  6, 2022, Alexandre Oliva <oliva@adacore.com> wrote:

> I'd much rather we could use -fmultiflags, a far more elegant
> arrangement IMHO, so...

> Ping?  https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597419.html

>> for  gcc/ChangeLog

>> * common.opt (fmultiflags): New.
>> * doc/invoke.texi: Document it.
>> * gcc.cc (driver_self_specs): Discard it.
>> * opts.cc (common_handle_option): Ignore it in the driver.


> Since this is kind of a build machinery feature, would anyone mind if I
> self-approved this with my build machinery maintainer hat on?

> Please raise your objection within one week if you do.

A month has gone by and no objections have been raised, so I'm finally
going ahead and checking it in.