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 7470F3858CDA for ; Fri, 28 Jul 2023 18:37:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7470F3858CDA 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,238,1684828800"; d="scan'208";a="14702421" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 28 Jul 2023 10:37:27 -0800 IronPort-SDR: Ca8/SBPRlsUr4/XCSqlI9dLOwXJOUqG1J3bqVJkZHTSUVU4TtdneEAJTwEL/jVn2UMza8awsdr YscgFWvG19n8b0MhqtW488aWGeotJydZOIUWWjf7yfVhcB6GyT0cPmlKeIQf0hSJ4sGEr3AZpj 7qbGKEz8n+PZfQRLI9ZMRewcNP8NXCeq0SvNmnR/UFT0WVh/spdpLAxcbd38YRr8FiRnpyM4ag Cj7rhRrpaObZiP/O0vD9UflFKSPSi2yHPDtwBEdf7SEfi1jz17Z4g/9ItSQmIRd38fxRzxlWu6 SAQ= Date: Fri, 28 Jul 2023 18:37:23 +0000 From: Joseph Myers To: Jakub Jelinek CC: Martin Uecker , Subject: Re: [RFC WIP PATCH] _BitInt bit-field support [PR102989] In-Reply-To: Message-ID: <7ded63b6-646d-d4f6-1855-db7df72cdcb1@codesourcery.com> References: <28223020-b396-2018-12bc-54b084d3ee8f@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-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3105.2 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,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 Fri, 28 Jul 2023, Jakub Jelinek via Gcc-patches wrote: > But I ran into a compiler divergence on _Generic with bit-field expressions. > My understanding is that _Generic controlling expression undergoes array > to pointer and function to pointer conversions, but not integral promotions > (otherwise it would never match for char, short etc. types). > C23 draft I have says: > "A bit-field is interpreted as having a signed or unsigned integer type > consisting of the specified number of bits" > but doesn't say which exact signed or unsigned integer type that is. Yes, the type used in _Generic isn't fully specified, just the type after integer promotions in contexts where those occur. > static_assert (expr_has_type (s4.c + 1uwb, _BitInt(389))); > static_assert (expr_has_type (s4.d * 0wb, _BitInt(2))); > static_assert (expr_has_type (s6.a + 0wb, _BitInt(2))); > That looks to me like LLVM bug, because > "The value from a bit-field of a bit-precise integer type is converted to > the corresponding bit-precise integer type." > specifies that s4.c has _BitInt(389) type after integer promotions > and s4.d and s6.a have _BitInt(2) type. Now, 1uwb has unsigned _BitInt(1) > type and 0wb has _BitInt(2) and the common type for those in all cases is > I believe the type of the left operand. Indeed, I'd expect those to pass, since in those cases integer promotions (to the declared _BitInt type of the bit-field, without the bit-field width) are applied. -- Joseph S. Myers joseph@codesourcery.com