From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id DFC0F385E038 for ; Tue, 26 Sep 2023 15:46:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DFC0F385E038 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-CSE-ConnectionGUID: wHQlxq+XTGCTfjNbwlYxxA== X-CSE-MsgGUID: iRAQcSETR0CJSnDOA+hosg== X-IronPort-AV: E=Sophos;i="6.03,178,1694764800"; d="scan'208";a="17872578" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 26 Sep 2023 07:46:40 -0800 IronPort-SDR: MCJ7/bdi5jOrRQLyaqaX2kgNLB670gbRz5spp0e7cT20CmgmHdXzAhnoCJqBhJ37p/w2LhuX83 D+LNeenyPpuv/Cc9PLTYVvlTjVtwHJlCbhB9W6U8m2rYCOnlr+hu2BOEFd/T3/5M2XoO+LQ3ju 7+4+YqmDvGHjXBUx/4WwFLw08+izC3ZZYyA+22hKhcjZqMI10JLAQrVizOSyXNtiIKpwl3Cldn YIyF1kHS4dQojiE+xNkcCAz/9yuHuWbq/flXJn1pUB6qaelQlQtyropEinAdVRt42cFbPGO41s d2Y= Date: Tue, 26 Sep 2023 15:46:35 +0000 From: Joseph Myers To: Sylvain Noiry CC: , Subject: Re: Complex numbers support: discussions summary In-Reply-To: Message-ID: <2ee88fc2-a1bc-ad0-51b4-bef227469de4@codesourcery.com> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-905241216-1695743196=:393175" 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=-3104.2 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: ---1152306461-905241216-1695743196=:393175 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT On Mon, 25 Sep 2023, Sylvain Noiry via Gcc wrote: > --> Idea: Add an attribute to the Tree complex type which specify pure real / > pure >    imaginary / full complex ? If you start from the implementation approach of lowering imaginary type operations in the front end, a flag on a REAL_TYPE would seem natural (and then the rest of the compiler could treat such types the same as other real types with the same machine modes). That would however mean that e.g. conversions to/from imaginary types in the front end are not the same thing as what you get from middle-end conversions (the former would apply the rules that converting imaginary to real or real to imaginary produces zero while preserving side effects from the expression converted; the latter would be a no-op conversion if the machine modes are the same), which has the potential to be confusing. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-905241216-1695743196=:393175--