From patchwork Tue Nov 1 21:30:29 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Palka X-Patchwork-Id: 1697909 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=MKuMHFHx; dkim-atps=neutral Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4N239P0RdGz23l6 for ; Wed, 2 Nov 2022 08:31:05 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 791DB385741E for ; Tue, 1 Nov 2022 21:31:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 791DB385741E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1667338262; bh=B1oGOaPsuPJ+XeBkLeSxO0Dp+xhL7nHqfc4x41Rey6k=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=MKuMHFHx3OqTH1M0D5w/rCjqpXt+Oi6FK9ZB2ExnLu4sFSGnPDoGc77TUYhUltEpL tR5vpFVSQajK5qQdutkgQfoGd4ERPLfj5p5I183X6L2J8dpSb7DdE0LwaEHz8srVbj 9fczx7AyNisW/i+WlPtK2ECQCQY8SQdbQxRxLUAE= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 786283858D28 for ; Tue, 1 Nov 2022 21:30:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 786283858D28 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-29-kj_GLeBFNamSWskSlXodEA-1; Tue, 01 Nov 2022 17:30:40 -0400 X-MC-Unique: kj_GLeBFNamSWskSlXodEA-1 Received: by mail-qt1-f198.google.com with SMTP id gc12-20020a05622a59cc00b003a5444280e1so76116qtb.13 for ; Tue, 01 Nov 2022 14:30:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=B1oGOaPsuPJ+XeBkLeSxO0Dp+xhL7nHqfc4x41Rey6k=; b=gio0ms+moHKqZ8rxrnGGRXRsCJQOUXtoWQEWzMktrfN2Py7V+N05pesEPGoW2XMb+I iUf7dCaRsxn9QL/QKOkCTea4gQitrL/weXn8jke4Rla3pi4gG0oIqA/vh6L8dXn1wwcF w4bxJe8C9bQSAckimbgBCFxbe6PH/obiUWNx0kXTKvYwfZZQ6NAkE28MfmgQwVmoJl66 hRZbx4Im5kj4GfH/yjX8xz/dJSDQojMweaBs6kObqm/MB9x2NqHCzH/TXjDKgAt1ysWv TXR9QGhLkeW7DrjCoWQblLVA1MzZwIhhy4+kZ2tSZlKw0gqocaFDp/vVw0hU4gfHfNLO qLBw== X-Gm-Message-State: ACrzQf1d8wLfI0+o+LNLniBbdekGW0tivkknARd+OlDvpxq4x/ujIPoO jugLDA/218V8zzuHh/NKIYYff5k0YrvOQjZ4uMPF71gOFgBCFLS3N3zX/WLyBW2g96hDHci2Z8l A+P6dqN/7fXRsnOZrLC+r0NnjL9SDYefyt+FSEsdGgjHSIuuivMV3U5ie54rU+Lg5oDM= X-Received: by 2002:a37:ad0d:0:b0:6fa:39fa:973f with SMTP id f13-20020a37ad0d000000b006fa39fa973fmr6701594qkm.563.1667338239291; Tue, 01 Nov 2022 14:30:39 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6CChaMwAg5+XPJ0JdoGQqfkPsXfhrdRnjg00brmH0KGvnW6bjD3BeD95P+hJqIz6XsvuoFXQ== X-Received: by 2002:a37:ad0d:0:b0:6fa:39fa:973f with SMTP id f13-20020a37ad0d000000b006fa39fa973fmr6701570qkm.563.1667338238979; Tue, 01 Nov 2022 14:30:38 -0700 (PDT) Received: from localhost.localdomain (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id z63-20020a37b042000000b006f9e103260dsm7173419qke.91.2022.11.01.14.30.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Nov 2022 14:30:38 -0700 (PDT) To: gcc-patches@gcc.gnu.org Subject: [PATCH] libstdc++: Fix ERANGE behavior for fallback FP std::from_chars Date: Tue, 1 Nov 2022 17:30:29 -0400 Message-Id: <20221101213029.940043-1-ppalka@redhat.com> X-Mailer: git-send-email 2.38.1.381.gc03801e19c MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-14.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable 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.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Patrick Palka via Gcc-patches From: Patrick Palka Reply-To: Patrick Palka Cc: jakub@redhat.com, libstdc++@gcc.gnu.org Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" The fallback implementation of floating-point std::from_chars for e.g. float80 just calls the C library's strtod family of functions. In case of overflow of the parsed result, the behavior of these functions is rigidly specified: If the correct value overflows and default rounding is in effect, plus or minus HUGE_VAL, HUGE_VALF, or HUGE_VALL is returned (according to the return type and sign of the value), and the value of the macro ERANGE is stored in errno. But in case of underflow, implementations are given more leeway: If the result underflows the functions return a value whose magnitude is no greater than the smallest normalized positive number in the return type; whether errno acquires the value ERANGE is implementation-defined. Thus we can (and do) portably detect overflow, but we can't portably detect underflow. However, glibc (and presumably other high-quality C library implementations) will reliably set errno to ERANGE in case of underflow too, and it will also return the nearest denormal number to the parsed result (including zero in case of true underflow). Since we can't be perfect here, this patch takes the best effort approach of assuming a high quality C library implementation that allows us to distinguish between a denormal parsed result and true underflow by inspecting the return value. Tested on x86_64-pc-linux-gnu, does this look OK for trunk? Dunno if we should backport this too. No test because we can't portably test this IIUC. libstdc++-v3/ChangeLog: * src/c++17/floating_from_chars.cc (from_chars_impl): In the ERANGE case, also check for a 0 return value before returning result_out_of_range, occurred, otherwise assume it's a denormal number. --- libstdc++-v3/src/c++17/floating_from_chars.cc | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/libstdc++-v3/src/c++17/floating_from_chars.cc b/libstdc++-v3/src/c++17/floating_from_chars.cc index a25ac5ce3aa..939c751f861 100644 --- a/libstdc++-v3/src/c++17/floating_from_chars.cc +++ b/libstdc++-v3/src/c++17/floating_from_chars.cc @@ -637,8 +637,13 @@ namespace { if (__builtin_isinf(tmpval)) // overflow ec = errc::result_out_of_range; - else // underflow (LWG 3081 wants to set value = tmpval here) + else if (tmpval == 0) // underflow (LWG 3081 wants to set value = tmpval here) ec = errc::result_out_of_range; + else // denormal value + { + value = tmpval; + ec = errc(); + } } else if (n) {