From patchwork Tue Jun 4 03:17:03 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kewen.Lin" X-Patchwork-Id: 1943070 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=QBctk+P6; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4VtbPb0m5Zz20KL for ; Tue, 4 Jun 2024 13:17:38 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4ADF13823588 for ; Tue, 4 Jun 2024 03:17:36 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 6D8873824AB7 for ; Tue, 4 Jun 2024 03:17:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6D8873824AB7 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6D8873824AB7 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717471037; cv=none; b=kFXTYeiJswuiaBk8nBoS8EALxHOdRnosnsBb45bXGAKtugGYFZDoF1sQU2uC1tFlDCZFMufDzv7RajcxDt5PeGc7yak7KdKjWixxctXF5WMjgRZQWMVSlgXA8IvwI84BT1fajXPC8bj1TAXMr92r0QIiVhlts7sw9gtgWiK2S7Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717471037; c=relaxed/simple; bh=pz0vfK/WD4AutOnrwsearabwqRH+aO65XyLcZLnUn2M=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=njS+N+qOSUNUa8qaw28eldAIeqN909LGrh8mc2vE3Fjv58dLMk7KLju9ubc7ACGlKuGDALXkF/wJ4BUFfEJhIoPR6VFMOnmizX64TATOf4mM8Oihmwd4F/2e6oP0SDkwKfpdohek3T+Jg6g8nUOvm97M8rLAWFW/jPq4PbamMpI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353726.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 4542oOW2002809; Tue, 4 Jun 2024 03:17:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc : content-transfer-encoding : content-type : date : from : in-reply-to : message-id : mime-version : references : subject : to; s=pp1; bh=7Doo0huGK+GahWawLOuZroWFDW1slpJ1MpwtbkdEkL8=; b=QBctk+P6MJelE/m3hbXMmcuofDx/YKnI3PoR4j5kmbC6+toq07KgkYWPjceh5NriZUKG vphexHiAvM8QyXVgdi8gR2kR4Rm3pdf4px3a47rIxjTJegfDlx+5cSVg9ESZjJOnnIJy 4Vj2zTJInNLkHgfE5KY8CrLSrxmifMh0pLp+2I6VFiJTbG+1M85JlzXgpt/IM7/hhK3x jMG0jJlLV5kE6T5Tj2dTGp49MTGyHGv4v2H9kL5ohN5THq7mDZIqRpY4/Ie+kQt/g9Fv AxxUbfq5ifnQaZRcwpf8BMC3UMhaZjH3UO0rJUdPeFlzbvdnkY3kxZxpHrPQq7wSJk2j nA== Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3yhtccr2g5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Jun 2024 03:17:14 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 4540Q6XP026549; Tue, 4 Jun 2024 03:17:13 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3yggp2u745-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Jun 2024 03:17:13 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 4543H9hO19792300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 4 Jun 2024 03:17:11 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 88BFC2004D; Tue, 4 Jun 2024 03:17:09 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C0C0120043; Tue, 4 Jun 2024 03:17:08 +0000 (GMT) Received: from [9.200.158.244] (unknown [9.200.158.244]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTP; Tue, 4 Jun 2024 03:17:08 +0000 (GMT) Message-ID: <579db142-fd34-0777-99ab-12052e03dd44@linux.ibm.com> Date: Tue, 4 Jun 2024 11:17:03 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: [PATCH 02/52 v2] d: Replace use of LONG_DOUBLE_TYPE_SIZE Content-Language: en-US To: Iain Buclaw Cc: gcc-patches@gcc.gnu.org References: <1717403769.e597uxrtpg.astroid@pulse.none> <58d3fbd4-562b-fc29-5bcd-bad898540e3d@linux.ibm.com> <1717424601.r19wofm6pm.astroid@pulse.none> From: "Kewen.Lin" In-Reply-To: <1717424601.r19wofm6pm.astroid@pulse.none> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: TNUsDIXkFgeXl6KoyNxC23danFxy6Xmc X-Proofpoint-GUID: TNUsDIXkFgeXl6KoyNxC23danFxy6Xmc X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16 definitions=2024-06-03_17,2024-05-30_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 clxscore=1015 suspectscore=0 impostorscore=0 mlxscore=0 phishscore=0 bulkscore=0 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000 definitions=main-2406040025 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Hi Iain, on 2024/6/3 22:39, Iain Buclaw wrote: > Excerpts from Kewen.Lin's message of Juni 3, 2024 10:57 am: >> Hi Iain, >> >> on 2024/6/3 16:40, Iain Buclaw wrote: >>> Excerpts from Kewen Lin's message of Juni 3, 2024 5:00 am: >>>> Joseph pointed out "floating types should have their mode, >>>> not a poorly defined precision value" in the discussion[1], >>>> as he and Richi suggested, the existing macros >>>> {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a >>>> hook mode_for_floating_type. To be prepared for that, this >>>> patch is to replace use of LONG_DOUBLE_TYPE_SIZE in d with >>>> TYPE_PRECISION of long_double_type_node. >>>> >>>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651209.html >>>> >>> >>> Thanks, one question though: Is TYPE_PRECISION really equivalent to >>> LONG_DOUBLE_TYPE_SIZE? >> >> Yes, it's guaranteed by the code in build_common_tree_nodes: >> >> long_double_type_node = make_node (REAL_TYPE); >> TYPE_PRECISION (long_double_type_node) = LONG_DOUBLE_TYPE_SIZE; >> layout_type (long_double_type_node); >> >> , the macro LONG_DOUBLE_TYPE_SIZE is assigned to TYPE_PRECISION of >> long_double_type_node, layout_type will only pick up one mode as >> the given precision and won't change it. >> >>> >>> Unless LONG_DOUBLE_TYPE_SIZE was poorly named to begin with, I'd assume >>> the answer to be "no". >> >> I'm afraid it's poorly named before. >> > > Thanks for confirming Kewen. > > I suspect then that this code is incorrectly using this macro, and it > should instead be using: > > int_size_in_bytes(long_double_type_node) > > as any padding should be considered as part of the overall type size for > the purpose that this field serves in the D part of the front-end. Got it, thanks for the explanation and suggestion. > > Are you able to update the patch this way instead? Otherwise I'm happy > to push the change instead. Sure, updated as below: Subject: [PATCH 02/52] d: Replace use of LONG_DOUBLE_TYPE_SIZE Joseph pointed out "floating types should have their mode, not a poorly defined precision value" in the discussion[1], as he and Richi suggested, the existing macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a hook mode_for_floating_type. To be prepared for that, this patch is to remove the only one use of LONG_DOUBLE_TYPE_SIZE in d. Iain found that LONG_DOUBLE_TYPE_SIZE is poorly named and used incorrectly before, so this patch follows his advice with int_size_in_bytes. [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651209.html Co-authored-by: Iain Buclaw gcc/d/ChangeLog: * d-target.cc (Target::_init): Use int_size_in_bytes of long_double_type_node to replace the expression with LONG_DOUBLE_TYPE_SIZE for c.long_doublesize assignment. --- gcc/d/d-target.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.43.0 BR, Kewen diff --git a/gcc/d/d-target.cc b/gcc/d/d-target.cc index 127b9d7ce7c..dd46e535891 100644 --- a/gcc/d/d-target.cc +++ b/gcc/d/d-target.cc @@ -163,7 +163,7 @@ Target::_init (const Param &) this->c.intsize = (INT_TYPE_SIZE / BITS_PER_UNIT); this->c.longsize = (LONG_TYPE_SIZE / BITS_PER_UNIT); this->c.long_longsize = (LONG_LONG_TYPE_SIZE / BITS_PER_UNIT); - this->c.long_doublesize = (LONG_DOUBLE_TYPE_SIZE / BITS_PER_UNIT); + this->c.long_doublesize = int_size_in_bytes (long_double_type_node); this->c.wchar_tsize = (WCHAR_TYPE_SIZE / BITS_PER_UNIT); this->c.bitFieldStyle = targetm.ms_bitfield_layout_p (unknown_type_node)