public inbox for
 help / color / mirror / Atom feed
From: Alexandre Oliva <>
To: Hans-Peter Nilsson <>
Subject: Re: [PATCH] Support multilib-aware target lib flags self-specs overriding
Date: Fri, 03 Jun 2022 04:15:15 -0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Hans-Peter Nilsson's message of "Wed, 1 Jun 2022 18:00:05 -0400 (EDT)")

On Jun  1, 2022, Hans-Peter Nilsson <> 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?)

Alexandre Oliva, happy hacker      
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <>

  reply	other threads:[~2022-06-03  7:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-20 19:13 Alexandre Oliva
2022-05-28  7:02 ` Alexandre Oliva
2022-06-01 22:00 ` Hans-Peter Nilsson
2022-06-03  7:15   ` Alexandre Oliva [this message]
2022-06-28 13:32     ` Alexandre Oliva
2022-10-06  8:24       ` Alexandre Oliva
2022-11-05  9:23         ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).