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.133.124]) by sourceware.org (Postfix) with ESMTPS id 05447385840F for ; Tue, 25 Jul 2023 19:15:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 05447385840F 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=1690312556; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UBkNmKFnCE/94TXmPj2oAk5H/wY8Yv7Eee0kBIinPDg=; b=Lrh5hWOgQ1RpvOX2l9Pf4ULt/TdFkSV+XILBILFVOO7cl869ZbKqupK3Yl4yZ3NV5pn6I4 DQJF6RqUgfyujuYrXMfSWwu7XM/OK1NFKT497HIH1qNRsx5jz+i+R8f0HYnqoY/LaVq2I/ +XRufoM7Q45tVOYytWp8gtv6yZ+aOvo= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-110-Q4w7gVvfOD-7wJ1hxzfyXw-1; Tue, 25 Jul 2023 15:15:55 -0400 X-MC-Unique: Q4w7gVvfOD-7wJ1hxzfyXw-1 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-31444df0fafso3430432f8f.2 for ; Tue, 25 Jul 2023 12:15:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690312554; x=1690917354; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UBkNmKFnCE/94TXmPj2oAk5H/wY8Yv7Eee0kBIinPDg=; b=cl+47PsZ0lQ4wuutMcGGTs3vR5qEyKIhhQ9QYIp54pMWc4KC9lJISmUK2Lz//HHcFx W0jcl74GxzA9sqXx1jKK0qUgL1ei+9HYG9O9KtjWCbD7bYpdNtjZmClb79QGqcFKchF6 GYcofFP4xiBNhIh2ZuFDfXLHhCZaNV6R56SD+r+nywim2/uIvgHnjw9zqkAZyeu08c5n UWEwkpxMtjvK5qOKxph8KCTIAODbFb2Gtateagfjf/26pNOugqYGwCJa2lnikAf0y7v/ cbDDYtNGSZ5gRvOOEmHMg1XX69I51+WeSxDjwhovk5xFnyPsSwaW0yDSAVVQQEblsIrg 3Awg== X-Gm-Message-State: ABy/qLa1TAcwXvhrDQfGf5y6ysbCx7Y5j5QMLPWaVl+yvy/HfsvmmBKA yTpJidtl2Z+aGcHMMcPlzA1qxHpZaU++kQTEKSr0C7paQMSBO7zjHM5EHWFp4wOdAn+PFzVzf2e RHZPfJfFy8/wkKufg5A== X-Received: by 2002:adf:cd03:0:b0:313:f429:f6e9 with SMTP id w3-20020adfcd03000000b00313f429f6e9mr10156185wrm.60.1690312554392; Tue, 25 Jul 2023 12:15:54 -0700 (PDT) X-Google-Smtp-Source: APBJJlGVNNgJ38GTvlonoWY1N/pV+4Fn+UkXXBNy9tGvbPbgI7FjfvNxQQ1GjRi33DDuooHwJUsa+Q== X-Received: by 2002:adf:cd03:0:b0:313:f429:f6e9 with SMTP id w3-20020adfcd03000000b00313f429f6e9mr10156172wrm.60.1690312554082; Tue, 25 Jul 2023 12:15:54 -0700 (PDT) Received: from [192.168.86.35] (128.red-81-33-16.staticip.rima-tde.net. [81.33.16.128]) by smtp.gmail.com with ESMTPSA id u2-20020a5d4342000000b003141f96ed36sm17382627wrr.0.2023.07.25.12.15.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Jul 2023 12:15:53 -0700 (PDT) Message-ID: Date: Tue, 25 Jul 2023 21:15:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755] To: Jakub Jelinek , Andrew MacLeod Cc: gcc-patches@gcc.gnu.org References: From: Aldy Hernandez In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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: The frange bits look fine to me, so if you feel confident in the math logic, go right ahead :). Thanks. Aldy On 7/24/23 18:01, Jakub Jelinek wrote: > 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 >