From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id ED047382D3FA for ; Wed, 7 Dec 2022 08:21:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED047382D3FA Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=googlemail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=googlemail.com Received: by mail-wr1-x42a.google.com with SMTP id f18so26952469wrj.5 for ; Wed, 07 Dec 2022 00:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gEUM5JoUxLxGiaF38oc1Yo/t4173r4dyx9Zx5dHqjTQ=; b=GkI/ONCXP5wzG+SaOfba7GRNAtVRpXWFXj0YB8hv8adQQ7by0H+g5zT4ichFm201Sx K792zZhAqouTuSg/FbM5eeStOgtxLbRMjJb06YhRpTfIgsn6sSxihWsEilvCKn7BxG7a 02CgBDNqMstR9/OwoiHt09GeKsIk5l37sD8zaQZF1G4z9+w6mxEM6FtoEWXgWpdjPji8 xAAvmXm0WY6Xgrl/VpTXBpUgPq4S/9/aiWRmK1BoXqRUv294YntQ32LHwX+UwDoS9vby b92Hs87VajS7Kx5I4i5u8q7RIuEWvOAUEld0o06zWKV2eL12QR9jwLbf0uuPMxAC3a+1 BDeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gEUM5JoUxLxGiaF38oc1Yo/t4173r4dyx9Zx5dHqjTQ=; b=hjLPvX3Tkty9ckl05bkDqzJkCkr9kN6L9Ic7CZKLOpDD9GD2W06NK9hIPRiiOLtzlj kyKjBCJTE7yuzBSHSCrYlpfcjB5YPK5fb4v6HsYNUWW+QKb/9gbWvvfCaMlYeND/+GcG YTOkNZ/d1CLoH0ohwe4Uf/oolqwWBxY9poI9TiymwHGlLtcuv0NDxqOUJll6/B39P7Ip pE0p5uI+SozO+uPwE1572UfGYRbAjPGPEKjUl1H9xwCxuwoHNCqHhFmTYpJLrdACjnkR 7kFYiMp6vWO6vOtFKKn4jHnUEc4E/hoPJJbrJNReW7lIEr0LhenRc7MFaIKDjF6kcS7z vB3g== X-Gm-Message-State: ANoB5pm+r5JXflv5S6XbUYkErIvvPfy1TDOCLw3iiWVQ1/TEYxrc1JWF Wib8jRI/I8A2fxnFn16/FWY= X-Google-Smtp-Source: AA0mqf4swS44wBF6eJiaxrS/sydfXr1JaSZtPHOaY3HzucHMsj8ZdZNE+JOqFTyIZGVsc0IciiVXvg== X-Received: by 2002:a5d:408f:0:b0:242:263e:3ba7 with SMTP id o15-20020a5d408f000000b00242263e3ba7mr20192906wrp.561.1670401284604; Wed, 07 Dec 2022 00:21:24 -0800 (PST) Received: from smtpclient.apple (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id b11-20020a05600c4e0b00b003c6c5a5a651sm927685wmq.28.2022.12.07.00.21.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Dec 2022 00:21:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC From: Iain Sandoe In-Reply-To: Date: Wed, 7 Dec 2022 08:21:22 +0000 Cc: Thomas Schwinge , Jeff Law , GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: <2E293A04-9D0B-4B26-88EB-C61E7B0104CF@googlemail.com> References: <20221121072526.103446-1-sebastian.huber@embedded-brains.de> <87k034s0lz.fsf@dirichlet.schwinge.homeip.net> <87tu278za7.fsf@dem-tschwing-1.ger.mentorg.com> To: Sebastian Huber X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi > On 7 Dec 2022, at 07:54, Sebastian Huber = wrote: >=20 >=20 >=20 > On 07.12.22 08:10, Thomas Schwinge wrote: >> Hi! >> On 2022-12-07T07:04:10+0100, Sebastian Huber = wrote: >>> On 06.12.22 22:06, Thomas Schwinge wrote: >>> I suppose I just fail to see some detail here, but: >>>=20 >>>> On 2022-11-21T08:25:25+0100, Sebastian = Huber wrote: >>>>> gcc/ChangeLog: >>>>>=20 >>>>> * 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. >>>>>=20 >>>>> gcc/gcc.cc | 9 ++++++++- >>>>> 1 file changed, 8 insertions(+), 1 deletion(-) >>>>>=20 >>>>> 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 >>>>>=20 >>>>> +/* 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 =3D ASM_DEBUG_SPEC; >>>>> static const char *asm_debug_option =3D ASM_DEBUG_OPTION_SPEC; >>>>> static const char *cpp_spec =3D CPP_SPEC; >>>>> -static const char *cc1_spec =3D CC1_SPEC; >>>>> +static const char *cc1_spec =3D CC1_SPEC SUBTARGET_CC1_SPEC; >>>>> static const char *cc1plus_spec =3D CC1PLUS_SPEC; >>>>> static const char *link_gcc_c_sequence_spec =3D = LINK_GCC_C_SEQUENCE_SPEC; >>>>> static const char *link_ssp_spec =3D LINK_SSP_SPEC; >>>>=20 >>>> ... doesn't this (at least potentially?) badly interact with any = existing >>>> 'SUBTARGET_CC1_SPEC' definitions -- which pe rabove get appended to >>>> 'cc1_spec'? >>>>=20 >>>> 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} \ >>>=20 >>> Oh, I came up with the name SUBTARGET_CC1_SPEC after a discussion on = the >>> mailing list >> I've put Iain in CC. >>> and I have to admit that I didn't check that it was >>> actually already in use. >> Always one of the first things I do. ;-) >>> What about renaming the loongarch/mips define >>> to LOONGARCH_CC1_SPEC and MIPS_CC1_SPEC? >> Also in use are a number of other 'SUBTARGET_[...]_SPEC' and >> corresponding 'subtarget_[...]_spec' in 'EXTRA_SPECS', for example: >> 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/mips.h: { "subtarget_asm_debugging_spec", = SUBTARGET_ASM_DEBUGGING_SPEC }, \ >> gcc/config/mips/mips.h: { "subtarget_asm_spec", = SUBTARGET_ASM_SPEC }, \ >> gcc/config/mips/mips.h- { "asm_abi_default_spec", "-" = MULTILIB_ABI_DEFAULT }, \ >> gcc/config/mips/mips.h- { "endian_spec", ENDIAN_SPEC }, = \ >> gcc/config/mips/mips.h: SUBTARGET_EXTRA_SPECS >> Do we need/want to keep the association of same-name >> upper-case/lower-case variants; in your proposal you'd then get >> '{ "subtarget_cc1_spec", MIPS_CC1_SPEC }', for example? (I didn't >> quickly grok all 'EXTRA_SPECS' usage.) >> Alternatively, what about renaming your 'SUBTARGET_CC1_SPEC' to >> 'CC1_SPEC_EXTRA' -- if that makes sense? >> static const char *cc1_spec =3D CC1_SPEC CC1_SPEC_EXTRA; >=20 > I was told that an operating system is the subtarget in this context. = So from the name SUBTARGET_CC1_SPEC is is clear who is in charge. This = is not clear from CC1_SPEC_EXTRA. Perhaps I was not precise enough (or misunderstood the full = requirement). Having reloaded some state on this thread=E2=80=A6 * The initial point was that target specs were an alternate mechanism = for doing what was required which I understood to be that there was "an OS-specific common spec = that needed to be added to multiple ports". * There are existing cases (at least Darwin is one) where this is done = - multiple ports (e.g. x86, rs6000) refer to common specs in the = gcc/config/ =20 - so, for example, the specs in gcc/config/i386/darwin.h pull in = common specs from gcc/config/darwin.h * there are also cases where this is specifically done in port code = (sometimes with =E2=80=9CSUBSUBTARGET_xxxx=E2=80=9D) =3D=3D=3D I made the comment that, IMO this is initially confusing when the OS = might be considered the target and the ISA the sub-target - however the = status quo in specs naming is the opposite way round. ( I do not wish add further confusion here - but attempting to clarify - = these styles of provision might not be suitable for the specific case, I = guess - anyway, at this point, I=E2=80=99ve got nothing more to add :) )=20= Iain >=20 >> But doesn't somehow this whole thing feel a bit like "chating the >> system"? ;-) >> Can't you actually achieve your thing (TLS model) via (new) = 'EXTRA_SPECS' >> in 'gcc/config/rtems.h', for example? >=20 > The EXTRA_SPECS definition seems to be target-specific. Not all = targets let an operating system define SUBTARGET_EXTRA_SPECS. The = SUBTARGET_EXTRA_SPECS would need to get propagated to the corresponding = specs, which seems to be also target-specific, for example for mips we = have: >=20 > #undef CC1_SPEC > #define CC1_SPEC "\ > %{G*} %{EB:-meb} %{EL:-mel} %{EB:%{EL:%emay not use both -EB and -EL}} = \ > %(subtarget_cc1_spec)" >=20 > I think going this route would lead to a lot of changes affecting all = targets. >=20 > --=20 > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.huber@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 >=20 > Registergericht: Amtsgericht M=C3=BCnchen > Registernummer: HRB 157899 > Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, = Thomas D=C3=B6rfler > Unsere Datenschutzerkl=C3=A4rung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/