From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id D23273858413 for ; Thu, 26 Aug 2021 15:52:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D23273858413 Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.0.43) with SMTP id 17QExtji004948; Thu, 26 Aug 2021 15:52:01 GMT Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by mx0b-00069f02.pphosted.com with ESMTP id 3ap3eash7p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Aug 2021 15:52:01 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 17QFnhfN192215; Thu, 26 Aug 2021 15:52:00 GMT Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2172.outbound.protection.outlook.com [104.47.59.172]) by userp3030.oracle.com with ESMTP id 3ajpm2t94v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Aug 2021 15:51:59 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lJcH1BFqbnz/uB16lpyVo1Ah36AvCPw4UEgTiZuWtN0W2tg+kmkUK4yMxA5QjYwJIFwlzUIuFmq3lx8hmlwt39/YRRmG31QjzqIh+odPQsTl57cgad0dU0WX38QZMTrSsSDcVXgg7bTh8vtDe/8SqCe4vIgppHhI6FqOVh31JuZqxaeUceMXUozIl5N6zoVyzsXwKcoP9PKSBSHtJHVTfc7Atj+2nrpxKGc0oe4OfQ/+olVpzYh8CEJUwIYHKxxGPb5m9pfXiRxRVShJ36BI/Y7hzPh3k2jxoNJ9TWU0RUWjSiFNY4tPwV7gSgHLIASdrMmCRfVdxxuq4QTLCe5PLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X06jVDhVDs8ec0SNo3QOeN318z0ePsUO/TlntVzmZpo=; b=F3gKkqw5xAiAcC5iyrT+xFOwb7l51uYRywDt/5jgOlvQ8yu/bNK3HqaInaa9gJONRRMqcYdBISSLm5SbCLLOCgd7rBI6z+NBWp+DaPpTugtJmk3beq1sGK5fhaOi2FCoXP5eSXkHWmzKIXz8wc+5je1BT1Fkn3SCoRg8yCCUccq+ZS4Iva3dQW6mXYtgxiwXNF/vpQUvej28gr2JCdV0hwdCXcutFfERlG5CkilpFI8VmhM8pp6wl15FZsPp+plCDo1qN3EmDRRwXqdk8DEbUScDy0wQfYs+LVyGnujx+29Q2wv1I534BBCj9rN1SaBiC9TZmpGVqyna/O758Ez7VA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from BYAPR10MB3208.namprd10.prod.outlook.com (2603:10b6:a03:159::10) by BYAPR10MB3734.namprd10.prod.outlook.com (2603:10b6:a03:127::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Thu, 26 Aug 2021 15:51:58 +0000 Received: from BYAPR10MB3208.namprd10.prod.outlook.com ([fe80::7c09:ef39:34f2:e79c]) by BYAPR10MB3208.namprd10.prod.outlook.com ([fe80::7c09:ef39:34f2:e79c%4]) with mapi id 15.20.4436.024; Thu, 26 Aug 2021 15:51:57 +0000 Subject: Re: [PATCH v3] Fix for powerpc64 long double complex divide failure To: Joseph Myers Cc: gcc-patches@gcc.gnu.org, segher@kernel.crashing.org References: <1628784193-9675-1-git-send-email-patrick.mcgehearty@oracle.com> <3c686d10-5e23-fbb8-66fd-756a80a91368@oracle.com> <8f29c866-46e5-1619-fe0b-22a72a617ec5@oracle.com> From: Patrick McGehearty Message-ID: <75d073d4-54c5-5601-3750-a674e07b1e95@oracle.com> Date: Thu, 26 Aug 2021 10:51:51 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ClientProxiedBy: SN6PR08CA0019.namprd08.prod.outlook.com (2603:10b6:805:66::32) To BYAPR10MB3208.namprd10.prod.outlook.com (2603:10b6:a03:159::10) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.154.163.185] (138.3.200.57) by SN6PR08CA0019.namprd08.prod.outlook.com (2603:10b6:805:66::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 15:51:57 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dfa99655-c07f-417c-77f6-08d968a96f66 X-MS-TrafficTypeDiagnostic: BYAPR10MB3734: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OoJbpVNT5W6G7sK2ml1YJMbMJ+cXF8t4kdhzNJ3jAPYXwMAUrD9QisrMyPDjUgjXKlCBpXEoB8GOOqXf8N50T/bzsHl3h75ydRkvWAFP+XsMAh4uT8I4aME0t/Xus9H5Y/hjxgzSOuVXLTs+CBuLYRhvSLfsN1A6D1Y0zZrctO3BHaED9CDRvCOOET+2GC8nCmRod5TuJfe83KtAtBPO3q/RxciF68+FeTSVhzSPSW0jUqxJZlXaxjncinN8JqXWHswCVw7My1IaVnYFdV3QjVgscsVq5nV9KYCiK6BvkmJKVGPI4TcuwK8cokOAwTb/EQblBK7GuiyktjXRfXAiQB/lvDcN3tu5uouJiQCrRv1A2BX9jjP1Si8RoqtEjwgFu/AAWh/lV1mpubcNcDPCvLTg4Oo2rfTCmuDmcSF5ys7s4nd/BHnEtIXPEY2MPDGosPuYw8wregQQ/DzaoS75o0it4ePYawRAjt8afWjKQUuhmaznb41y9YPVPFsr0N+U6vu12Ej4j5qIDqU5JQViixt3eGcGHsNOCjS1/domDtnNtzIK+IAxTgIvvVqu1V1uQNWQukamgls04+IKXgcB6h6yg5j2g/CuxZI00rwYDawYAjgBl5+BHro3+rX/QhvCCnYVC/CiELzS/wzlW7AoMv2KNy00Jx5f2wM6Z8n4nEdqpbV+zcHHp9TwiwwghnAEK7bT3sGWp0YpRIz9iy9rJ24YxRdnoDBcmkyJi6nCazZn0b2C4sMVJxEm7ASCjwL5+soqnKNBQSWxlF6+/0FmOg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR10MB3208.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(66556008)(8676002)(53546011)(66476007)(36756003)(956004)(83380400001)(186003)(2616005)(38350700002)(4326008)(38100700002)(316002)(6916009)(6666004)(31696002)(508600001)(6486002)(66946007)(26005)(52116002)(16576012)(86362001)(2906002)(5660300002)(8936002)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T2syMm1iUTVway9DSU02TzBpWm56cjBOWnhheEI1QjU1ek9ZVjI0U0ZiMXMw?= =?utf-8?B?L0tVbHczTmU1a1VBKzk1RDcra2xNeldYUGorM0Fzb09XYzlCMmVWNnZyQ1Vr?= =?utf-8?B?Y2hqN1pvb1JWZjFkeG51bkJFdTF4NG5ORkE2NzlLTktLZnUxbjRSNm5uNWFy?= =?utf-8?B?Zk1leEdqMmJlRG9zS2NsMDFWNk1lREphaU9YWGVsYXh0eE13WmlPUUFRelNO?= =?utf-8?B?aFdMTHZFZmpWb0hncFlRc201bllNNGZuUWJIQlpZYjY4R0NDcHEwamo2cU9M?= =?utf-8?B?UUxRaFBtSkNWZ2J4b2R2dnYrbFFoRjRwYTBPMklYZUxIYzYyc3FiY0FnQUps?= =?utf-8?B?YUVtWVhKZG9scVAvM281NStHZ1l4TGlNak0rRWgxSmg4cDVPM2psb2tmUnFh?= =?utf-8?B?dERUclNwaUdQQ1hpakN6Z1c3aXRCak1MSS9FRHI3ZzVVZmFKdDBuMzVuVGlX?= =?utf-8?B?QzRmWVphZmc1WFhoU2xFL3pLMUc1SjliQmVwLzIzSSt4SWxkZU0vUTlmeFBZ?= =?utf-8?B?NjhrdWpJaGJTb0xpOXp3ZFJlU1oxM2s0VGlZVzVueFdjUzBJU2RuUnRyZWpw?= =?utf-8?B?cnAzcjF0dnhrdEVKZldQSStnMzZQd3FqdDBMbkZpK2dteURIRU1uSkFkVnp0?= =?utf-8?B?V1ArdGgyRlJ0YUFKMC96dHNKdVJDMTVSM3ozc0RKWjkrRlA2dXNmVjZXL0ov?= =?utf-8?B?VkVpQ2Myb1VwcWk3elg5UVU5UzkwUE5yMG9taTkrYkwvdEdoZ2dyMXljSDg4?= =?utf-8?B?UlA4KzBSRHhYYldNUDNVV1VWR29wL2l2N3VraGpDRmNNMThMVEVPM0VGSHEz?= =?utf-8?B?NUY2d29IMnJWK05CbXFBU3krT2ZlWDhabHpMTjl3U2hwQUxWZkF3QmVRRldr?= =?utf-8?B?TDdNMVdkZWJSTmpKTGZFMSswMi9NWDJzV3h0ODNoa0NCclZRcDE2ZWQxaWNu?= =?utf-8?B?eHdjZSszTVJHYkVteDNSR0tsNUpOMVhPdVQ1SlNPY1Fyb1N2V0NvZWhUa3dv?= =?utf-8?B?YjZmOXM0N2cwMzg5SUFGNHNhT1lucjJyclZ3SmFla0xmTUZ3dnM3eXdFbXlT?= =?utf-8?B?dGJQVUc0YzZ4M0dLWGtjUm5pRm50QWVkb1dJTWFJeUNRZmI4QnQ4Y0JnSTFE?= =?utf-8?B?L1VFbnh3b21udTBPbDJMdGtlb2lGVTZyWTB4dzAvakgwSmg2QlZZUytJZ292?= =?utf-8?B?TUpvK3BRT05NY3RMWjR5SVRjUnJrUWNKcXJyUDlLQzNqMkdkcExxcnlMYUtL?= =?utf-8?B?d1dQL1JkUGZ2RlI1NjI1c0Yxb2JPeWtmN1ljL2podDE5bWRoamk4UmVyenlj?= =?utf-8?B?Uk9WWExZY3lHOS9YdkN5NnFpZ084Wno0MW9Cc2VyZWFBdUtqQ0VTS3hpUGgx?= =?utf-8?B?TGZhM2tSYVNkeHRrZHl3ZDd1THJtcXFUZm4zNlRaYmlKTzUwQWZPSDhxTkVR?= =?utf-8?B?VS9aK083YVN6cENNVkhVbk5iTzlHeVhlc0ZMTzNCZGtOZ1BHcTlseGRqTUlI?= =?utf-8?B?akc5blJoSEk3VStLTGJPeDZJQWNrK1Rlb0I3OEFGV043TGIwM3A3aFRyL0dm?= =?utf-8?B?cHpPeS8zbUN2VHg3T1hsV0tjdE0vWm1CTjNTeFZmc0Z4MHprc1h6UjN1U0Vz?= =?utf-8?B?UzF1YXp0L1RabVBPb2dKS0tDb0JWeXpMazJzMEhyWW9KRWUxUmJVaXRBVlVi?= =?utf-8?B?THVVVlpPV3VCTy9oV29KVXRXYXE4VnZlSU1KN2hLSkloYVIremwzM1I5R0U5?= =?utf-8?Q?P7tiFrhx+S/PyAKnHVHZ8Rkq0hGPqnqf01PuFvI?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: dfa99655-c07f-417c-77f6-08d968a96f66 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3208.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 15:51:57.9142 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 6l7V7DqEXjV3fYy7jv9vc5avjr16xmIDrzDRXbqFqqF6YcBrxMS3PA886EQpiT+URz2Ub55YfUafHM1BYMuW2RPOT2a8AkIwkrIqXw15u0k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB3734 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10088 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 malwarescore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108260089 X-Proofpoint-ORIG-GUID: gxdrkMHQ1m0H44D3LeT9560XRFg5AbWZ X-Proofpoint-GUID: gxdrkMHQ1m0H44D3LeT9560XRFg5AbWZ X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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, 26 Aug 2021 15:52:14 -0000 Apologies in advance for the length of this reply. Details seemed necessary to be sure we are on the same page of understanding. Aug 26, 2021 by Patrick McGehearty The only IBM machines I have current access to are in the gcc fsf farm. All studies were done on gcc135.fsffrance.org Linux gcc135.osuosl.org 4.18.0-80.7.2.el7.ppc64le /usr/bin/gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) /usr/lib64/libc.so.6 linked to libc-2.17.so yum list glibc shows the version 2.17-307.el7.1 while version 2.17-324.el7_9 is available. I'm concerned that the old environment on gcc135.fsffrance.org is not showing me a typical build environment for IBM linux users with more modern environments. I am also concerned that I may not be setting my environment completely to use current components. - - - - I built gcc from current upstream gcc srcs, replacing KF references in libgcc/config/rs6000/_divkc3.c with DF references and installed it in $HOME/usr. For the following test purposes, I added the following to my local environment: PATH=$HOME/usr/bin:$PATH export PATH LD_LIBRARY_PATH=$HOME/usr/lib64:$HOME/usr/lib export LD_LIBRARY_PATH The only complex divide routines in $HOME/usr/lib64/libgcc_s.so.1 are: __divdc3, __divsc3, __divtc3 Compiling a simple c=a/b (for long double complex a,b,c) yields a call to __divtc3 Compiling with -mabi=ieeelongdouble yields a call to __divkc3 When I link the version with the call to __divkc3 into an executable, the executable contains __divkc3. I just can't tell where the linker is finding it. - - - - Using this environment, I tried building upstream gcc with __LIBGCC_KF_MAX__ and other #defines in  libgcc/config/rs6000/_divkc3.c #ifndef __LONG_DOUBLE_IEEE128__ #define RBIG   (__LIBGCC_KF_MAX__ / 2) #define RMIN   (__LIBGCC_KF_MIN__) #define RMIN2  (__LIBGCC_KF_EPSILON__) #define RMINSCAL (1 / __LIBGCC_KF_EPSILON__) #define RMAX2  (RBIG * RMIN2) #else The KF case got errors of the sort: ‘__LIBGCC_KF_MAX__’ undeclared ‘__LIBGCC_KF_EPSILON__’ undeclared ‘__LIBGCC_KF_MIN__’ undeclared These values were supposed to be created by gcc/c-family/c-cppbuiltin.c. They depend on KF being part of FOR_EACH_MODE_IN_CLASS (mode_iter, MODE_FLOAT) {   const char *name = GET_MODE_NAME (mode); ... } Apparently KF is not one of the mode names when building in this environment. I've spent some time trying to understand where/how the MODE_FLOAT class is constructed, but I have not been able to pinpoint what's going wrong. - - - - When I replace the various _KF_ values with _DF_ values, the compiler builds to completion. In other testing I have confirmed that the rs6000/_divkc3.c code does expect to be generating code for IEEE mode. - - - - - - - - - - - - - - - - - - - - - - - - When I compile/run the new test program cdivchkld.c with the old compiler and -lm in the default IBM 128bit mode, it aborts as expected. When I attempt to use the -mabi=ieeelongdouble -lm, the compiler aborts with an internal error. Clearly ieeelongdouble is not supported on this old compiler. When I compile/run cdivchkld.c with my new compiler with _DF_ values in _divkc3.c, it runs to completion without aborting. That is why I believed rs6000/_divkc3.c affected the behavior of IBM 128bit mode. When I compile/link cdivchkld.c with -mabi=ieeelongdouble -lm I get cdivchkld.c:(.text+0x3c4): undefined reference to `__fmaxieee128' caused by the reference in the code to LDBL_MAX_EXP. - - - - - I suspect that part of the KF issue is that the general environment on gcc135.fsffrance.org is relatively old. That is, it includes some include files or libraries from before the KF/TF option for handling IBM vs IEEE format was added to gcc. My use of $HOME/usr for PATH and LD_LIBRARY_PATH may be inadequate for bypassing the older environment. I don't have access to a current (el8 or later) IBM environment. - - - - - - - - - - - - - - - - - - - - - - - - With moderate study, I find I still don't really understand how the make files are building both _divtc3.c and _divkc3.c as appropriate for machines with/without HW support for IEEE128. It will be some time before I could get enough ahead on my primary assignments to learn what I need to know to gain that understanding. I am concerned that in some IBM environments, the build process will fall back to using the code in libgcc/libgcc2.c for IBM 128bit float complex divide. In that case, the current 1/__LIBGCC_TF_EPSILON__ value will generate an infinity result which would be suboptimal. Changing __LIBGCC_TF_EPSILON__ to __LIBGCC_DF_EPSILON__ for all platforms avoids the overflow without changing the final answers. It only has the effect of doing some scaling without possible overflow/underflow when it is not necessary. I propose for my next patch I change libgcc/libgcc2.c to use __LIBGCC_DF_EPSILON__ instead of __LIBGCC_TF_EPSILON__ in addition to the most recent changes in rs6000/_divkc3.c. That set of changes will allow the upstream gcc to build on the IBM build farm on fsf as well as allowing the new test results to pass. I'm not sure how else to approach this issue for a short term solution. - Patrick McGehearty (patrick.mcgehearty@oracle.com) On 8/13/2021 12:12 PM, Joseph Myers wrote: > On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote: > >> If _divkc3.c is not intended to provide a version of complex divide >> that handles IBM-128 format, then where should that option be handled? > That should be the function __divtc3. (A single libgcc binary supports > multiple long double formats, so libgcc function names referring to > floating-point modes need to be understood as actually referring to a > particular *format*, which may or may not correspond to the named *mode* > depending on the compilation options used. Thus, libgcc functions with > "tf" or "tc" in their names, on configurations such as > powerpc64le-linux-gnu that ever supported IBM long double, always refer to > IBM long double. It's up to the back end to ensure that, when building > with TFmode = binary128, TCmode and KCmode division both get mapped to > __divkc3 while ICmode division gets mapped to __divtc3; when building with > TFmode = IBM long double, KCmode division should still be __divkc3, ICmode > division should still be __divtc3, and TCmode division should be __divtc3 > in that case as well.) > >> Do I need add a special case for >> #ifndef __LONG_DOUBLE_IEEE128__ >> in the complex divide code in libgcc/libgcc2.c? > That macro is architecture-specific so shouldn't be tested there. Doing > things differently if __LIBGCC_TF_MANT_DIG__ == 106 would be reasonable > (if it fixes the observed problem!), however; there are a few places in > generic libgcc code that check for MANT_DIG == 106 to handle IBM long > double differently. > >> And, for completeness, does gcc support LDBL for non-IEEE on >> any platform besides IBM? > I believe TFmode is IEEE binary128 everywhere except for those powerpc > configurations where it's IBM long double. >