From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10089.outbound.protection.outlook.com [40.107.1.89]) by sourceware.org (Postfix) with ESMTPS id 07C433894C2F for ; Tue, 24 Nov 2020 13:42:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 07C433894C2F Received: from AM5PR0601CA0079.eurprd06.prod.outlook.com (2603:10a6:206::44) by DBBPR08MB6282.eurprd08.prod.outlook.com (2603:10a6:10:20c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Tue, 24 Nov 2020 13:41:59 +0000 Received: from AM5EUR03FT032.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:0:cafe::c5) by AM5PR0601CA0079.outlook.office365.com (2603:10a6:206::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Tue, 24 Nov 2020 13:41:58 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; gcc.gnu.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;gcc.gnu.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT032.mail.protection.outlook.com (10.152.16.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Tue, 24 Nov 2020 13:41:58 +0000 Received: ("Tessian outbound 814be617737e:v71"); Tue, 24 Nov 2020 13:41:58 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 0146417ffaa30542 X-CR-MTA-TID: 64aa7808 Received: from 60fa34565774.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 0C71FBE7-103B-4C7B-8D0E-59FF6ACF40A9.1; Tue, 24 Nov 2020 13:41:52 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 60fa34565774.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 24 Nov 2020 13:41:52 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TUR3054NNYEYWGoP44o8fiBMshShHwS4u5r1EZYpqYrFFrtdbxhDGzi0/JnSgHZ7tdTZjc09v6ihAaEAcuA8ym99Je1ZdF9/PenS86hKzZ0tnQO/tF11dS3Cr4+xii5cKIOSyss6/6hqkeXRN9uQmNT/t4iCR3GIZFkJrdiDF2G5CZwjTBReO6x9lA8KTW/s67oEBS8ppDDIkSrR04JkhoQCYnLrI6RnUtF4VRGV9OywGA7Xt+fXuHtrjm3LvGF7TOHVxjxE4+lEeA46KXa5sECT70hys+/LsLzcfHZpt9iX/mSg2X7GSlo4Qu1MSehdjcgM0YMlpYKwsCdlLTsTzA== 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=4pZg9Q/4czJDCgNBFeL7emqrFAGe9pg9lp68esfL8NA=; b=T9s3yKARK1Au2g4LeNj45kAJpnMUQkwjUX+uJj2e5mrItJTIfhC/mvsDMUbWuqPA0NgbukwG/b2+fCtwKpGgB27QqAf3NChnLA7k7+5Nqf3J5nLqcRne0EnpIRbZAvEuKhFA/hSWsHJtkEJKJr0iZVsBIVeqEnNdGozbQ1OGKnxh9xbGtp/iGxchUt76u+tnhS2EgQWBrpsvRjjTeiNaDKnSwrqIWgxyCUILXpuUHtzARNvruQrs3co6rAh7KY1zviuuK3zr+chTi8kmtxJQPK/QHA46+ltdW0qjPiaxa2RJVwsxvRC9rIJlJMMJDWUdPc244UH5heDQ+zigWxCZ5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none Authentication-Results-Original: gotplt.org; dkim=none (message not signed) header.d=none;gotplt.org; dmarc=none action=none header.from=arm.com; Received: from PR3PR08MB5564.eurprd08.prod.outlook.com (2603:10a6:102:87::18) by PA4PR08MB6095.eurprd08.prod.outlook.com (2603:10a6:102:ec::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Tue, 24 Nov 2020 13:41:50 +0000 Received: from PR3PR08MB5564.eurprd08.prod.outlook.com ([fe80::ac13:db5:ef4:2dd2]) by PR3PR08MB5564.eurprd08.prod.outlook.com ([fe80::ac13:db5:ef4:2dd2%4]) with mapi id 15.20.3589.030; Tue, 24 Nov 2020 13:41:50 +0000 Date: Tue, 24 Nov 2020 13:41:48 +0000 From: Szabolcs Nagy To: Siddhesh Poyarekar Cc: gcc@gcc.gnu.org, Siddhesh Poyarekar via Libc-alpha , Florian Weimer , Carlos O'Donell , joseph@codesourcery.com Subject: Re: unnormal Intel 80-bit long doubles and isnanl Message-ID: <20201124134146.GL20578@arm.com> References: <6663b7b7-7e5b-8987-bd0d-82bceb772951@gotplt.org> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6663b7b7-7e5b-8987-bd0d-82bceb772951@gotplt.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [217.140.106.54] X-ClientProxiedBy: LO2P265CA0010.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::22) To PR3PR08MB5564.eurprd08.prod.outlook.com (2603:10a6:102:87::18) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from arm.com (217.140.106.54) by LO2P265CA0010.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Tue, 24 Nov 2020 13:41:49 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: fc3272f4-e9c8-459c-a549-08d8907eb73f X-MS-TrafficTypeDiagnostic: PA4PR08MB6095:|DBBPR08MB6282: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:9508;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: t0Qf5b11wys8n9cv4TagYXoshpnaPecm76WgO/EPHzIFFjXhtbqdg/Azq4dpr6lhyQq8qsWdMNoaTnFJDFDJ0RfcQBhf7vpGd7Q2rES83CAKbqawbZENKObyUBVW672kM8C0QZ0lai67HcJbrz5nCtgSrG27tWWNEVxJXgf0/LrGQoiKGB1gKXJZZtOKAxjK3KZ/ic/97BkQd/pzx4cXV9QOD34WaXWf6Uwkz+RG91lEfIEPhPQAwY4/wUUkb/PDlAls8XxoViAD/4zKX2F56d1uqTj2DPoZ7PvCq8KAU6E8O9wM99I2oVXggbK9S8min/dOdhF5s7l3wmFbU10v36a2R6uAwNk4BwYBABrLN99neC7Sr1ZbCY0DppMy/808MeF/VgyKbN/vDbfqubBnYA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR08MB5564.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(376002)(136003)(366004)(396003)(54906003)(316002)(1076003)(2906002)(6916009)(33656002)(966005)(8936002)(4326008)(8886007)(66946007)(26005)(52116002)(66476007)(66556008)(55016002)(7696005)(8676002)(2616005)(956004)(83380400001)(478600001)(186003)(16526019)(86362001)(5660300002)(44832011)(36756003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: wGbsFqjVxlszOIdGLG1XiLP1ALrwFe9fJAbkrc9LuYqNMvpvxTXxq+FFDqzXL8H6YAjk/t5axarR2RA0cS8xBRh8U2y3L35mIq3x885IBkCTtMI5eUYAXOTXOKzH9vYq/luR3PhubZkbSYIDOT8zhSgg16eWxonomUkirSn5jHKLd5eG80ypr8gcIsErP7PjuiMrE3I9lhSk84OlcRIcxVdq2cSjUS8BZBuvaqvdVayOfzaTLRX2B3VtWdqaR528IHfsgw1Ad962zh/HCVNpsvPp+NUeRQQS545UV/uqqCXMxlzZhOeT2YD01mJgH/9L6plp3y/fc0lbJRzJPtNFs/I+JQ81BcxQzqxSpnG2ygVTCNquzlAasEtZhT6n/uc7+0q9SXUiTjOVz/yb7kp3ZqiP+9edeYz/NUB8kInx4L1vZntM+sXP0rR8u34xRaorYHda1x0l/U7INgeaHbPA496SGbTFd5CuqKPy/nUHiNhZvY/gJQK6gtm/ToEICxUqodD3NfWo0EIB2VXy6hH/xthvcdjqy1QqsAyMEY8J1f0JzDt8vBxutWv4Lk6y7A/cuecTS4hcmrsFWWGcy5nG4RoWFFxnNmANNhtt9lBunDsOP0YBAz4A/xqg4kRVl4uzs8Vu5KHu8wWNYwHWbwNRXVhQa+BD21y6GTfq+oBq3tFyJy7VufHBvREWrFnjc+ZuuP5Sy0rfGBcPGDJxhYzNgqbnYWCRL5e2cahVhQ6msxzXlv8Y2v5jJrnJ0jYOfjK2fgncbLKeKcdAq00HKFrzbIj+VdXIyZtc6O+RVOvxHPCa42L1kUWEJo3OLcTWiyEJw97g9BsjHBJTx7UVxWmbE8XYzg8qReuemJ+zKFhXnRMZJ3mx0vL8Wbx9RjpKwSvFH9J/vmXluzYMhP3vjkUAVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6095 Original-Authentication-Results: gotplt.org; dkim=none (message not signed) header.d=none;gotplt.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 8426b33d-4840-41ce-8189-08d8907eb203 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 10xYv6lou8Hp2vU7oHZ12ukUIKiDMsW/aefH1BKyTPx2Kkt8ro7ogNSDVJUfOCB4fTULWHLWsklAWDO0cn8Eq3i+PN2y7yT01i8cBbQoAsMJmwpZ3iWBJIqbSSFIdjGbV9qx710/ybZnesPZOjPRoHmLbRXLA9ndKBkEKtqM9RVHwBJv/4lstaSCBsq2Kk68pZB9qkmff4R0o8ma+Cccz+3P9FeVB69QdIxgowjbpO6o2VITNCy/dOhyWwaHFR5ibm+gjYQOOJVlFJMxTf0kRnqTAtX0FXXR+6WkJisewTpiHnl3QTU+FhzYlTZKIWEhONnHI+HNCdsqZI4KwoubBwkyeKbq0ufiI8echKlt7d2TVUTtpoqVe7lnJEFlo4K5WMaeTnJdFlJuy3/kuek+TSj+fTxFg/auFBaCRkrjwbsVI0hR0EAt/uRLZLwV8TFyFPhNxaWZC4er4OHGEvNH8CHiOO8tffJzoQvy1kw3jQU= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(39860400002)(376002)(346002)(136003)(46966005)(5660300002)(81166007)(55016002)(6862004)(82310400003)(1076003)(4326008)(70206006)(36906005)(70586007)(8886007)(54906003)(82740400003)(47076004)(356005)(316002)(83380400001)(8936002)(956004)(16526019)(36756003)(186003)(2616005)(86362001)(8676002)(336012)(44832011)(966005)(26005)(33656002)(478600001)(2906002)(107886003)(7696005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2020 13:41:58.7016 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fc3272f4-e9c8-459c-a549-08d8907eb73f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6282 X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 13:42:05 -0000 The 11/24/2020 16:23, Siddhesh Poyarekar wrote: > Hi, > > The Intel 80-bit long double format has a concept of "unnormal" numbers that > have a non-zero exponent and zero integer bit (i.e. bit 63) in the mantissa; > all valid long double numbers have their integer bit set to 1. Unnormal > numbers are mentioned in "8.2.2 Unsupported Double Extended-Precision > Floating-Point Encodings and Pseudo-Denormals" and listed in Table 8-3 in > the Intel 64 and IA-32 Architectures Software Developer’s Manual Volume > 1:Basic Architecture. > > As per the manual, these numbers are considered unsupported and generate an > invalid-operation exception if they are used as operands to any floating > point instructions. The question of this email is how the toolchain > (including glibc) should treat these numbers since as things stand today, > glibc and gcc disagree when it comes to isnanl. ideally fpclassify (and other classification macros) would handle all representations. architecturally invalid or trap representations can be a non-standard class but i think classifying them as FP_NAN would break the least amount of code. > glibc evaluates the bit pattern of the 80-bit long double and in the > process, ignores the integer bit, i.e. bit 63. As a result, it considers > the unnormal number as a valid long double and isnanl returns 0. i think m68k and x86 are different here. > > gcc on the other hand, simply uses the number in a floating point comparison > and uses the parity flag (which indicates an unordered compare, signalling a > NaN) to decide if the number is a NaN. The unnormal numbers behave like > NaNs in this respect, in that they set the parity flag and with > -fsignalling-nans, would result in an invalid-operation exception. As a > result, __builtin_isnanl returns 1 for an unnormal number. compiling isnanl to a quiet fp compare is wrong with -fsignalling-nans: classification is not supposed to signal exceptions for snan. > > So the question is, which behaviour should be considered correct? Strictly > speaking, unnormal numbers are listed separately from NaNs in the document > and as such are distinct from NaNs. So on the question of "is nan?" the > answer ought to be "No". > > On the flip side, the behaviour described (and experienced through code) is > exactly the same as a NaN, i.e. a floating point operation sets the parity > flag and generates an invalid-operation exception. So if it looks like a > NaN, behaves like a NaN, then even if the document hints (and it is just a > hint right, since it doesn't specifically state it?) that it's different, it > likely is a NaN. What's more, one of the fixes to glibc[1] assumes that > __builtin_isnanl will do the right thing. > > The third alternative (which seems like a step back to me, but will concede > that it is a valid resolution) is to state that unnormal input to isnanl > would result in undefined behaviour and hence it is the responsibility of > the application to ensure that inputs to isnanl are never unnormal. > > Thoughts? > > Siddhesh > > [1] https://sourceware.org/git/?p=glibc.git;h=0474cd5de60448f31d7b872805257092faa626e4