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 13262384F03B for ; Thu, 12 Aug 2021 16:47:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 13262384F03B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: dP/jaNduyZ2Pl6brPuayTBuDOFY0JTEgsNraUjKXg7nDuqCtEcvLP/CBdFI4asoriRV/7+iSev 0KYHaBWwW0rVwzNi++jw6Kv8bKZlh2O4VY5I2rHLtI0UBYv216A5QP2Qet2kaJ0DVK1FjeCaGQ 7RO+OTppfqWq+n7YrMpIfJhKqLDvbYGUc7w0APXAZBJHZ0+RgeSPaUT96BtcsqXHAPsSfDDzvG f7silsB5VvSTg6/+j61nRqEaQnRoQRqqYTec8NRrYYucw4v6wkre2uJWeleLixQiKmGJNQ9d4J F0nwKPtsXrj8k6uRk/zE7wvX X-IronPort-AV: E=Sophos;i="5.84,316,1620720000"; d="scan'208";a="64794499" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 12 Aug 2021 08:47:48 -0800 IronPort-SDR: zcon+piT5VLy/Hhv06YJCuE3jQYDwSPLFddrIkw2E5CqwJqkmfYMe0+6VPi/rmWNkPdIihMtVg sPYA1dPRG3IRaNJpfZ8j91uubbWdRcTLzPINaepVLN2e4FOJxDGEjVl19uWGfEClbq9l9h/Hs+ /RXkrxFmlJfg1D305xgUDTm2sYbcT9eSeoCDh+iQr+nY+/Eui6vWWmwUZj7AVXkB6WhBDgk7vX BZ9gZnCCWairDIiF0VpMg68dmlAmQAFa4Seg5E7pTxWRfxw0z5t3DSOSEUnWjuf1AW78FQ6z/S PDI= Date: Thu, 12 Aug 2021 16:47:42 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Patrick McGehearty CC: , Subject: Re: [PATCH v3] Fix for powerpc64 long double complex divide failure In-Reply-To: <3c686d10-5e23-fbb8-66fd-756a80a91368@oracle.com> Message-ID: References: <1628784193-9675-1-git-send-email-patrick.mcgehearty@oracle.com> <3c686d10-5e23-fbb8-66fd-756a80a91368@oracle.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3119.1 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 16:47:50 -0000 On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote: > > This file includes quad-float128.h, which does some remapping from TF to > > KF depending on __LONG_DOUBLE_IEEE128__. > > > > I think you probably need to have a similar __LONG_DOUBLE_IEEE128__ > > conditional here.  If __LONG_DOUBLE_IEEE128__ is not defined, use > > __LIBGCC_KF_* macros instead of __LIBGCC_TF_*; if __LONG_DOUBLE_IEEE128__ > > is defined, use __LIBGCC_TF_* as above.  (Unless the powerpc maintainers > > say otherwise.) > --------- > The KF version fails when in IBM128 mode while the DF version works > for that mode. KFmode should always be IEEE binary128. IFmode should always be IBM long double. TFmode may be one or the other depending on command-line options. "in IBM128 mode" should mean that the compiler defaults to long double being IBM long double and TFmode being IBM long double. But in that mode, KFmode should still be IEEE binary128 and it should still be correct to use the KF constants in this file. > My understanding of ibm FP mode build procedure is minimal, > but it seems that the _divkc3.c routine is built for both IEEE128 > and IBM128 modes. If built for IBM128 mode (i.e., compiler defaults to TFmode = IBM long double), it should still build a function __divkc3 which takes IEEE binary128 arguments and uses IEEE binary128 (KFmode) constants. If you were changing the L_divtc3 case in libgcc2.c to use different constants in the case where TFmode is IBM long double, that would make sense to me. It's changing an IEEE-only file for an IBM long double issue that doesn't make sense. If this change causes some test using IBM long double to pass where it failed before, that indicates a build system problem somewhere. -- Joseph S. Myers joseph@codesourcery.com