public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Sebastian Huber <sebastian.huber@embedded-brains.de>
Cc: Thomas Schwinge <thomas@codesourcery.com>,
	 Jeff Law <jeffreyalaw@gmail.com>,
	 gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC
Date: Wed, 07 Dec 2022 09:50:50 +0000	[thread overview]
Message-ID: <mptzgbz8rut.fsf@arm.com> (raw)
In-Reply-To: <d8d24781-4137-0368-a091-2429be6818ec@embedded-brains.de> (Sebastian Huber's message of "Wed, 7 Dec 2022 07:04:10 +0100")

Sebastian Huber <sebastian.huber@embedded-brains.de> writes:
> On 06.12.22 22:06, Thomas Schwinge wrote:
>> Hi!
>> 
>> I suppose I just fail to see some detail here, but:
>> 
>> On 2022-11-21T08:25:25+0100, Sebastian Huber<sebastian.huber@embedded-brains.de>  wrote:
>>> gcc/ChangeLog:
>>>
>>>        * gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
>>>        (cc1_spec): Append SUBTARGET_CC1_SPEC.
>>> ---
>>> v2: Append SUBTARGET_CC1_SPEC directly to cc1_spec and not through CC1_SPEC.
>>>      This avoids having to modify all the CC1_SPEC definitions in the targets.
>>>
>>>   gcc/gcc.cc | 9 ++++++++-
>>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/gcc.cc b/gcc/gcc.cc
>>> index 830ab88701f..4e1574a4df1 100644
>>> --- a/gcc/gcc.cc
>>> +++ b/gcc/gcc.cc
>>> @@ -706,6 +706,13 @@ proper position among the other output files.  */
>>>   #define CPP_SPEC ""
>>>   #endif
>>>
>>> +/* Subtargets can define SUBTARGET_CC1_SPEC to provide extra args to cc1 and
>>> +   cc1plus or extra switch-translations.  The SUBTARGET_CC1_SPEC is appended
>>> +   to CC1_SPEC.  */
>>> +#ifndef SUBTARGET_CC1_SPEC
>>> +#define SUBTARGET_CC1_SPEC ""
>>> +#endif
>>> +
>>>   /* config.h can define CC1_SPEC to provide extra args to cc1 and cc1plus
>>>      or extra switch-translations.  */
>>>   #ifndef CC1_SPEC
>>> @@ -1174,7 +1181,7 @@ proper position among the other output files.  */
>>>   static const char *asm_debug = ASM_DEBUG_SPEC;
>>>   static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
>>>   static const char *cpp_spec = CPP_SPEC;
>>> -static const char *cc1_spec = CC1_SPEC;
>>> +static const char *cc1_spec = CC1_SPEC SUBTARGET_CC1_SPEC;
>>>   static const char *cc1plus_spec = CC1PLUS_SPEC;
>>>   static const char *link_gcc_c_sequence_spec = LINK_GCC_C_SEQUENCE_SPEC;
>>>   static const char *link_ssp_spec = LINK_SSP_SPEC;
>> ... doesn't this (at least potentially?) badly interact with any existing
>> 'SUBTARGET_CC1_SPEC' definitions -- which pe rabove get appended to
>> 'cc1_spec'?
>> 
>>      gcc/config/loongarch/gnu-user.h-   and provides this hook instead.  */
>>      gcc/config/loongarch/gnu-user.h:#undef SUBTARGET_CC1_SPEC
>>      gcc/config/loongarch/gnu-user.h:#define SUBTARGET_CC1_SPEC GNU_USER_TARGET_CC1_SPEC
>>      gcc/config/loongarch/gnu-user.h-
>>      --
>>      gcc/config/loongarch/loongarch.h-#define EXTRA_SPECS \
>>      gcc/config/loongarch/loongarch.h:  {"subtarget_cc1_spec", SUBTARGET_CC1_SPEC}, \
>>      gcc/config/loongarch/loongarch.h-  {"subtarget_cpp_spec", SUBTARGET_CPP_SPEC}, \
>>      --
>>      gcc/config/mips/gnu-user.h-   and provides this hook instead.  */
>>      gcc/config/mips/gnu-user.h:#undef SUBTARGET_CC1_SPEC
>>      gcc/config/mips/gnu-user.h:#define SUBTARGET_CC1_SPEC GNU_USER_TARGET_CC1_SPEC
>>      gcc/config/mips/gnu-user.h-
>>      --
>>      gcc/config/mips/linux-common.h-
>>      gcc/config/mips/linux-common.h:#undef  SUBTARGET_CC1_SPEC
>>      gcc/config/mips/linux-common.h:#define SUBTARGET_CC1_SPEC                                           \
>>      gcc/config/mips/linux-common.h-  LINUX_OR_ANDROID_CC (GNU_USER_TARGET_CC1_SPEC,                     \
>>      --
>>      gcc/config/mips/mips.h-
>>      gcc/config/mips/mips.h:/* SUBTARGET_CC1_SPEC is passed to the compiler proper.  It may be
>>      gcc/config/mips/mips.h-   overridden by subtargets.  */
>>      gcc/config/mips/mips.h:#ifndef SUBTARGET_CC1_SPEC
>>      gcc/config/mips/mips.h:#define SUBTARGET_CC1_SPEC ""
>>      gcc/config/mips/mips.h-#endif
>>      --
>>      gcc/config/mips/mips.h-#define EXTRA_SPECS                                                  \
>>      gcc/config/mips/mips.h:  { "subtarget_cc1_spec", SUBTARGET_CC1_SPEC },                              \
>>      gcc/config/mips/mips.h-  { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC },                              \
>>      --
>>      gcc/config/mips/r3900.h-/* By default (if not mips-something-else) produce code for the r3900 */
>>      gcc/config/mips/r3900.h:#undef SUBTARGET_CC1_SPEC
>>      gcc/config/mips/r3900.h:#define SUBTARGET_CC1_SPEC "\
>>      gcc/config/mips/r3900.h-%{mhard-float:%e-mhard-float not supported} \
>
> Oh, I came up with the name SUBTARGET_CC1_SPEC after a discussion on the 
> mailing list and I have to admit that I didn't check that it was 
> actually already in use. What about renaming the loongarch/mips define 
> to LOONGARCH_CC1_SPEC and MIPS_CC1_SPEC?

One drawback to that is that people might have their own spec files
that reference the existing names.  Typically those would be produced
by using -dumpspecs and editing the output.  I think we only really
support that if people regenerate the specs files for each release,
but for targets like MIPS that don't see much activity, it's probably
easy to get away without doing that.

How about going back to Jose's suggestion from the original thread
of using OS_CC1_SPEC?  The patch is OK with that change if no-one
objects in 24 hours.

Thanks,
Richard

  parent reply	other threads:[~2022-12-07  9:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21  7:25 Sebastian Huber
2022-11-21  7:25 ` [PATCH v2 2/2] RTEMS: Use local-exec TLS model by default Sebastian Huber
2022-12-06 21:06 ` [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC Thomas Schwinge
2022-12-07  6:04   ` Sebastian Huber
2022-12-07  7:10     ` Thomas Schwinge
2022-12-07  7:54       ` Sebastian Huber
2022-12-07  8:21         ` Iain Sandoe
2022-12-07  9:50     ` Richard Sandiford [this message]
2022-12-09  7:03       ` Sebastian Huber

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=mptzgbz8rut.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=sebastian.huber@embedded-brains.de \
    --cc=thomas@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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