From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 524353858D38 for ; Tue, 13 Jun 2023 15:45:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 524353858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="6.00,240,1681200000"; d="scan'208";a="8664100" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 13 Jun 2023 07:45:21 -0800 IronPort-SDR: CjxJeuDlCaOIBWL36Wu+xgnpCT2zzPcAqrweDZgZ4t3btUMjCWe1QuoHwZdGmkE46n1DBITf4t ySaThDPWcDsen9IfQ9RhTcAyqK7AerNwCe80qfzufva/cyRGg7VjvIx+094h9P+BQg67xcvNdM GS5XAXdGN1ANjsM0T1zrR725sYSa7YVarIte+ovB2keryZ0VpJyMUJ14jqMuju2vvFQuFfy569 eI4Yn+Nw4USseXPhd/E9fzQfXs89Yq9Tg/2FxZdHKa5JNbMraBBd681RZ83BrMtjyHxuaamOJK iAI= Date: Tue, 13 Jun 2023 15:45:17 +0000 From: Joseph Myers To: Jakub Jelinek CC: Marek Polacek , , Subject: Re: [RFC] Add stdckdint.h header for C23 In-Reply-To: Message-ID: <3eb8ffea-759b-8be-56c-4859583ec432@codesourcery.com> References: <68578b43-939-1879-9676-2ea55249a2c5@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-14.mgc.mentorg.com (139.181.222.14) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3105.8 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_PASS,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: On Tue, 13 Jun 2023, Jakub Jelinek via Gcc-patches wrote: > Yeah, having say __builtin_{clz,ctz,ffs,popcount,parity} variants which would > be typegeneric and would allow say any normal integral or _BitInt type > (or just unsigned versions thereof?) would be useful. Even without _BitInt > we have the problem that we don't have builtins for __uint128_t. > > One question is if we should keep them UB on zero input or hardcode some particular > behavior for clz/ctz. The backend defaults might not be appropriate, I > think if we'd make it non-UB, using the precision of the type would be > reasonable, whatever it is (__builtin_clzb ((unsigned _BitInt(126)) 0) > might be 126 etc.). FWIW the C2x stdbit.h operations all have defined semantics on special cases, except for the stdc_bit_ceil operations (where there's an NB comment on CD2 to be considered at next week's WG14 meeting requesting defined semantics there as well). They're also all for unsigned arguments. (Note there are also NB comments requesting removal of some of the operations as duplicates or near-duplicates of others.) The stdbit.h header does seem naturally to be something for libc, given that (a) it has a lot of functions, not just type-generic macros, and (b) the type-generic macros are generally easy to implement (at least for the types supported in the standard) in a way that doesn't depend on any compiler extensions (or even on _Generic, many of them can be implemented just to call the function for unsigned long long). It makes sense in due course for GCC to know the names there (after any get removed) as built-in functions, but mapping in a header to existing __builtin_* is generally easy until then. -- Joseph S. Myers joseph@codesourcery.com