From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 226E73858C50 for ; Tue, 21 Nov 2023 05:59:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 226E73858C50 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 226E73858C50 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700546355; cv=none; b=eYZGZJeNbwm/OmlTHv3RI7CWxRpGEQqWNRjqpFo3P5WrLtyPb8vViIMYj3I1ZWLheDyyrkFnxdAUusR49cMUJ6IrNk2iYmEZXe2pageA91YTbZShPlp5xSSKgzW7qD1Yz3w3eyZt+vejesVg6wHbC2t+5+EprfXb0DiFoO8AxxM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700546355; c=relaxed/simple; bh=Z/OyG7TsbA4N6bFSoQbgiLDoV3SxZdKRiQdhFtKxfX4=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=uyEJ/TSFhluoay6fUfBCXems+nYtP3KU4YXXp0tY9I6zuM1ifwyYJAfFM9RKpWHK5TbquCSQJdcfy2i776mOKaHslr+Yq9j2/D0ll5rI2eKf3ALOwaRPF17hAIBuSw0653NeRlrQez7J+2Uk5p/VB32OLC+fmu5gSR5blBAPdKw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.0.221] (84-115-221-205.cable.dynamic.surfer.at [84.115.221.205]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4SZDGG1gnzz3wVZ; Tue, 21 Nov 2023 06:59:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1700546343; bh=qB51sCupDGnf1f4gKpk1spZdNM71eOUH58ND/Ro81BM=; h=Subject:From:To:Cc:Date:In-Reply-To; b=d9f5fRtEsF/FQjzfTaOyAR1JiGcFQzWxbDO3c7jmA+v1Q69ftJqkdPi72NLYj5y6v QZG93nMuvjJOv654hp3QJwNiMSQzuW1Pnf08OF6mlTFmFUpMaYXUXxHtu+7c7eeyPh ltG3WIDLjb4SThWaWdgsly76D3vbDTkjUplcZyTk= Message-ID: <826473adb228dad2135f6a3ec9d27660bab8b56f.camel@tugraz.at> Subject: Re: [PATCH] c-family, middle-end: Add __builtin_c[lt]zg (arg, 0ULL) exception From: Martin Uecker To: gcc-patches@gcc.gnu.org Cc: rguenther@suse.de, Joseph Myers , jakub Jelinek Date: Tue, 21 Nov 2023 06:59:01 +0100 In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -0.4 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: (corrected address) > On Mon, 20 Nov 2023, Jakub Jelinek wrote: >=20 > > On Mon, Nov 20, 2023 at 08:37:55AM +0000, Richard Biener wrote: > > > > I'm not sure about that, it would be nice for them to be usable the= re, > > >=20 > > > Btw, I think that {( .. )} should be made usable in sizeof () and > > > possibly even in at least C++ constant expressions (not sure about C)= . > >=20 > > I believe the problkem is having new VAR_DECLs in those which actually > > aren't file scope/namespace scope variables but there is no function > > DECL_CONTEXT to attach to them. So, it probably wouldn't be one aftern= oon > > change to allow that. There is an open bug about this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D93239 But the required feature is simpler than full statement=C2=A0 expression, essentially let x =3D y in z where x is an identifier and y and z are expression, and this should be much easier to implement. I thought about an extension to _Generic which would be useful here: _GNU_Generic(y, int x1: z1, float x2: z2) or even _GNU_Generic(y, default x: z) which would be useful in general. > >=20 > > > > but I think e.g. none of Joseph's implementation of those macros > > > > made them usable there (except inside of sizeof/typeof/typeof_unqua= ll) > > > > and I don't see a requirement in the C23 standard that they must be= usable > > > > in constant expressions. > > > > The versions I've posted on Thursday were usable there except for > > > > stdc_has_single_bit (but that actually can be implemented that way = too) > > > > and stdc_bit_floor. And the version I haven't posted that used the= 3 > > > > patches posted on Saturday would have all functions usable when the > > > > argument to those macros is a constant expression. > > > >=20 > > > > BTW, if we go route of implementing all of the stdc_ type-generic m= acros > > > > as builtins, we could as well not implement that way the following = 4 > > > > # define stdc_first_leading_one(x) (__builtin_clzg (x, -1) + 1U) > > > > # define stdc_first_trailing_one(x) (__builtin_ctzg (x, -1) + 1U) > > > > # define stdc_count_ones(x) ((unsigned int) __builtin_popcountg (x)= ) > > > > # define stdc_has_single_bit(x) ((_Bool) (__builtin_popcountg (x) = =3D=3D 1)) > > > > which are implementable without any new extensions. > > >=20 > > > I'd rather do all of those necessary as builtins instead of hacking > > > around limitations. If we don't want to solve those limitations in > > > a more generic way. > >=20 > > Ok, I can prepare a patch for that, shouldn't be that hard. > > Do you want all 14, or just the 10 and leave the above 4 with the > > above definitions? >=20 > I'd say all of them for consistency, we can parse/gimplify them to > the open-coded variants then. For use of _Generic with _BitInt one would need some kind of _BitInt_Width(x) macro/builtin that returns the width as an constant expressions, which would also be useful in general. Then one could write: _Generic(x, int a: foo, _BitInt(_BitInt_Width(x)): bar); With this and an extension as suggested above, I think one could solve this in a generic way. Martin > > > And of course nobody would write > > >=20 > > > const int x =3D sizeof (stdc_first_leading_one (5)); > > >=20 > > > that's just stupid ... (but oh well). > >=20 > > Well, standard testsuite needs to include that at least. > > But of course, if it is usable in constant expressions, > > unsigned a =3D stdc_bit_width ((unsigned _BitInt(824)) 4359873498567354= 89657489657468954768954674589674598uwb * 4987655896754986754896754896754896= 7549867548967456uwb); > > etc. can be useful in constant expressions. > >=20 > > Jakub > >=20 > >=20