From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 096793858C5E for ; Mon, 24 Jul 2023 16:02:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 096793858C5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690214535; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=y9yUkKKl8pBrpcy8HMI4EAdMVEcT1en3+aOITPYOUjs=; b=LOQBn4VncAfvIA5xZgSKlmlUDjchUdR/y/UgneqMJYgC4D/iYMQBmq0l/9LRzP9k8P3H2F Fl1VSQY2RkcXBS6DZNAguiTLOzn7QccM2Qntl+JIN6yAnMefROHYe1on2b448WJqblVBTU aXfkL0q85EKxnn1gOx8e+wl9S72WSK4= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-503-J5XfxL3aOomHbfNgJCnYMg-1; Mon, 24 Jul 2023 12:01:59 -0400 X-MC-Unique: J5XfxL3aOomHbfNgJCnYMg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 116B638008A7 for ; Mon, 24 Jul 2023 16:01:58 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C9A472166B25; Mon, 24 Jul 2023 16:01:57 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 36OG1tvP3987116 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 24 Jul 2023 18:01:56 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 36OG1tCX3987113; Mon, 24 Jul 2023 18:01:55 +0200 Date: Mon, 24 Jul 2023 18:01:55 +0200 From: Jakub Jelinek To: Aldy Hernandez , Andrew MacLeod Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755] Message-ID: Reply-To: Jakub Jelinek MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! IEEE754 says that x + (-x) and x - x result in +0 in all rounding modes but rounding towards negative infinity, in which case the result is -0 for all finite x. x + x and x - (-x) if it is zero retain sign of x. Now, range_arithmetic implements the normal rounds to even rounding, and as the addition or subtraction in those cases is exact, we don't do any further rounding etc. and e.g. on the testcase below distilled from glibc compute a range [+0, +INF], which is fine for -fno-rounding-math or if we'd have a guarantee that those statements aren't executed with rounding towards negative infinity. I believe it is only +- which has this problematic behavior and I think it is best to deal with it in frange_arithmetic; if we know -frounding-math is on, it is x + (-x) or x - x and we are asked to round to negative infinity (i.e. want low bound rather than high bound), change +0 result to -0. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and after a while for 13.3? I'm afraid rushing this so late into 13.2... 2023-07-24 Jakub Jelinek PR tree-optimization/110755 * range-op-float.cc (frange_arithmetic): Change +0 result to -0 for PLUS_EXPR or MINUS_EXPR if -frounding-math, inf is negative and it is exact op1 + (-op1) or op1 - op1. * gcc.dg/pr110755.c: New test. --- gcc/range-op-float.cc.jj 2023-07-23 19:32:20.832434105 +0200 +++ gcc/range-op-float.cc 2023-07-24 09:41:26.231030258 +0200 @@ -324,6 +324,24 @@ frange_arithmetic (enum tree_code code, bool inexact = real_arithmetic (&value, code, &op1, &op2); real_convert (&result, mode, &value); + /* When rounding towards negative infinity, x + (-x) and + x - x is -0 rather than +0 real_arithmetic computes. + So, when we are looking for lower bound (inf is negative), + use -0 rather than +0. */ + if (flag_rounding_math + && (code == PLUS_EXPR || code == MINUS_EXPR) + && !inexact + && real_iszero (&result) + && !real_isneg (&result) + && real_isneg (&inf)) + { + REAL_VALUE_TYPE op2a = op2; + if (code == PLUS_EXPR) + op2a.sign ^= 1; + if (real_isneg (&op1) == real_isneg (&op2a) && real_equal (&op1, &op2a)) + result.sign = 1; + } + // Be extra careful if there may be discrepancies between the // compile and runtime results. bool round = false; --- gcc/testsuite/gcc.dg/pr110755.c.jj 2023-07-21 10:34:05.037251433 +0200 +++ gcc/testsuite/gcc.dg/pr110755.c 2023-07-21 10:35:10.986326816 +0200 @@ -0,0 +1,29 @@ +/* PR tree-optimization/110755 */ +/* { dg-do run } */ +/* { dg-require-effective-target fenv } */ +/* { dg-require-effective-target hard_float } */ +/* { dg-options "-O2 -frounding-math" } */ + +#include + +__attribute__((noipa)) float +foo (float x) +{ + if (x > 0.0) + { + x += 0x1p+23; + x -= 0x1p+23; + x = __builtin_fabsf (x); + } + return x; +} + +int +main () +{ +#ifdef FE_DOWNWARD + fesetround (FE_DOWNWARD); + if (__builtin_signbit (foo (0.5))) + __builtin_abort (); +#endif +} Jakub