From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id B26873858D20 for ; Wed, 9 Aug 2023 21:18:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B26873858D20 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.01,160,1684828800"; d="scan'208";a="15726258" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 09 Aug 2023 13:18:01 -0800 IronPort-SDR: zO78jb9IwU576nX1xooOqgEbkw/SQ0zFEaMYVpqIaVjtldxGs5RjJRDR8iFt2FiWRLP0GjtxzW KegSjpSub9bxyEl4JE459QbluliJTveICi5sR/U2WxLeEkxAtue0J5k3f5Z/AIc56DtScShBdu 23GExAQizaBfNza1NhLaZrP0tFLOFXVk6Siwt25jT5qRBahQMZmB/r21bwGOsvtFyNBHB3ApBN Sw1fqtO15j+8ChTnSJo6fJCJOe5NdbmKnjgmSn+EJovEIiY+Ta4872yON9qAJgW2/zdYCCRLD8 8bM= Date: Wed, 9 Aug 2023 21:17:57 +0000 From: Joseph Myers To: Jakub Jelinek CC: Richard Biener , Uros Bizjak , , Subject: Re: [PATCH 0/12] GCC _BitInt support [PR102989] In-Reply-To: Message-ID: <696ce2b2-5ac2-8946-29de-d5dd4fb3aff2@codesourcery.com> References: 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=-3104.9 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,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: On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs > mention how those should be passed/returned; in a limited way they are > supported internally because the internal functions into which > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE as a > hack to return 2 values without using references/pointers What happens when the usual arithmetic conversions are applied to operands, one of which is a complex integer type and the other of which is a wider _BitInt type? I don't see anything in the code to disallow this case (which would produce an expression with a _Complex _BitInt type), or any testcases for it. Other testcases I think should be present (along with any corresponding changes needed to the code itself): * Verifying that the new integer constant suffix is rejected for C++. * Verifying appropriate pedwarn-if-pedantic for the new constant suffix for versions of C before C2x (and probably for use of _BitInt type specifiers before C2x as well) - along with the expected -Wc11-c2x-compat handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes. -- Joseph S. Myers joseph@codesourcery.com