From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 0150C385E017 for ; Mon, 31 Oct 2022 18:24:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0150C385E017 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="5.95,228,1661846400"; d="scan'208";a="88636458" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 31 Oct 2022 10:24:18 -0800 IronPort-SDR: 7mhY755EE5lQXY8XOq7dnYDrAtbxT2cb/lIvk3yxm5vyuckj0t0AUcJHHmV44maN9DlxlW3IjK FeA9YPgHTDT9JxyBnjgc7GHodRwgyWdE6cYoyZ+4FAI1p4vsDot1HnMI+StYvRPpwEt1t27jyb MGsy1TzYxIopWODKV6805JIoPNy9C5an+Kaz4HgbCCBK/AxtBEeAg6Njd02t9L4jxtcWSO7/Dw +4axB/c4C9G9LCB4BURU6PviKq1TW67hNBvM3xcZ9VS0z7g6KeM2Qb1G0LMTDGd4ffKoATyyqz zBA= Date: Mon, 31 Oct 2022 18:24:13 +0000 From: Joseph Myers To: Jeff Law CC: FX , , Jakub Jelinek Subject: Re: [PATCH] Add __builtin_iseqsig() In-Reply-To: Message-ID: <46e27067-6cb9-a5fc-f96-394515bcf9d@codesourcery.com> References: <127A04DF-0BC1-40B4-956A-B22C39F97BF9@gmail.com> <3FD18835-D09C-4073-B23F-DD1038D4D0AC@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-64684129-1667240653=:197816" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-13.mgc.mentorg.com (139.181.222.13) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3110.3 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP 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: ---1152306461-64684129-1667240653=:197816 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Fri, 28 Oct 2022, Jeff Law via Gcc-patches wrote: > Joseph, do you have bits in this space that are going to be landing soon, or > is your C2X work focused elsewhere?  Are there other C2X routines we need to > be proving builtins for? I don't have any builtins work planned for GCC 13 (maybe adjustments to __builtin_tgmath semantics to match changes in C2X, but that's a keyword, not a built-in function). See for my comments on (the tests in) this patch. Lots of functions could sensibly have built-in versions, whether for inline expansion, optimization for constant arguments or both. Note that for those added from TS 18661-4, it will be more convenient to add glibc support once MPFR 4.2 is out so that gen-auto-libm-tests doesn't depend on an unreleased MPFR version, and likewise MPFR 4.2 will be needed for optimizing those functions for constant arguments. But other highlights for which built-in functions might make sense in some cases include: issubnormal, iszero (see bugs 77925 / 77926, where Tamar Christina's patch needed to be reverted); probably the fromfp functions (but note that the interface in C2X is different from that in TS 18661-1 and I haven't yet implemented those changes in glibc); the functions that round their result to a narrower type (supported as hardware operations on current POWER, I think); the functions bound to new maximum / minimum operations from IEEEE 754-2019 (some of which are supported by RISC-V instructions). Also the functions; I expect to implement those for glibc largely using existing built-in functions, but more direct built-in function support for the names may make sense. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-64684129-1667240653=:197816--