This patch fixes the oversight.
Tested on x86-64 Linux.
Pushed.
On Wed, Nov 9, 2022 at 12:05 AM Aldy Hernandez wrote:
>
> Sigh, one more thing.
>
> There are further possibilities for a NAN result, even if the operands
> are !NAN and the result from frange_arithmetic is free of NANs.
> Adding d
Sigh, one more thing.
There are further possibilities for a NAN result, even if the operands
are !NAN and the result from frange_arithmetic is free of NANs.
Adding different signed infinities.
For example, [-INF,+INF] + [-INF,+INF] has the possibility of adding
-INF and +INF, which is a NAN. Sin
On Tue, Nov 8, 2022 at 10:11 AM Jakub Jelinek wrote:
>
> On Tue, Nov 08, 2022 at 09:44:40AM -0800, Andrew Waterman wrote:
> > On Tue, Nov 8, 2022 at 3:20 AM Jakub Jelinek via Gcc-patches
> > wrote:
> > >
> > > On Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy Hernandez wrote:
> > > > As suggested up
On Tue, Nov 08, 2022 at 09:44:40AM -0800, Andrew Waterman wrote:
> On Tue, Nov 8, 2022 at 3:20 AM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy Hernandez wrote:
> > > As suggested upthread, I have also adjusted update_nan_sign() to drop
> > > the NAN
On Tue, Nov 8, 2022 at 3:20 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy Hernandez wrote:
> > As suggested upthread, I have also adjusted update_nan_sign() to drop
> > the NAN sign to VARYING if both operands are NAN. As an optimization
> > I keep the
On Tue, Nov 8, 2022 at 3:11 PM Jakub Jelinek wrote:
>
> On Tue, Nov 08, 2022 at 03:06:53PM +0100, Aldy Hernandez wrote:
> > +// If either operand is a NAN, set R to the combination of both NANs
> > +// signwise and return TRUE.
>
> This comment doesn't describe what it does now.
> If either operan
On Tue, Nov 08, 2022 at 03:06:53PM +0100, Aldy Hernandez wrote:
> +// If either operand is a NAN, set R to the combination of both NANs
> +// signwise and return TRUE.
This comment doesn't describe what it does now.
If either operand is a NAN, set R to NAN with unspecified sign bit and return
TRUE
tached patch in testing.
Aldy
From 8da4fc39cc73f0ae785463bd5f371223fa59027e Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Thu, 13 Oct 2022 08:14:16 +0200
Subject: [PATCH] [PR24021] Implement PLUS_EXPR range-op entry for floats.
This is the range-op entry for floating point PLUS_EXPR. It&#x
On Tue, Nov 08, 2022 at 03:02:40PM +0100, Aldy Hernandez wrote:
> From d02ce8eaf16d2fc6db6472268fd962e09c2fd81e Mon Sep 17 00:00:00 2001
> From: Aldy Hernandez
> Date: Mon, 7 Nov 2022 14:18:57 +0100
> Subject: [PATCH] Provide normalized and denormal format version of
> real_isdenormal.
>
> Imple
On Tue, Nov 8, 2022 at 2:15 PM Jakub Jelinek wrote:
>
> On Tue, Nov 08, 2022 at 01:47:58PM +0100, Aldy Hernandez wrote:
> > On Tue, Nov 8, 2022 at 12:07 PM Jakub Jelinek wrote:
> > >
> > > On Mon, Nov 07, 2022 at 04:38:29PM +0100, Aldy Hernandez wrote:
> > > > From d214bcdff2cb90ad1eb808d29bda6fb
On Tue, Nov 08, 2022 at 02:47:35PM +0100, Aldy Hernandez wrote:
> Well, perhaps we should just nuke update_nan_sign() altogether, and
> always keep the sign varying?
>
> inline bool
> propagate_nans (frange &r, const frange &op1, const frange &op2)
> {
> if (op1.known_isnan () || op2.known_isnan
On Tue, Nov 8, 2022 at 2:25 PM Jakub Jelinek wrote:
>
> On Tue, Nov 08, 2022 at 02:06:58PM +0100, Aldy Hernandez wrote:
> > + gcc_checking_assert (!r.nan_signbit_p (sign1));
> > + if (op1_nan && op2_nan)
> > +{
> > + // If boths signs agree, we could use that sign, but IEEE754
> > +
On Tue, Nov 08, 2022 at 02:06:58PM +0100, Aldy Hernandez wrote:
> + gcc_checking_assert (!r.nan_signbit_p (sign1));
> + if (op1_nan && op2_nan)
> +{
> + // If boths signs agree, we could use that sign, but IEEE754
> + // does not guarantee this for a binary operator. The x86_64
> +
On Tue, Nov 08, 2022 at 01:47:58PM +0100, Aldy Hernandez wrote:
> On Tue, Nov 8, 2022 at 12:07 PM Jakub Jelinek wrote:
> >
> > On Mon, Nov 07, 2022 at 04:38:29PM +0100, Aldy Hernandez wrote:
> > > From d214bcdff2cb90ad1eb808d29bda6fb98d510b4c Mon Sep 17 00:00:00 2001
> > > From: Aldy Hernandez
>
7b16077ebc0c1e7bf3c33d Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Thu, 13 Oct 2022 08:14:16 +0200
Subject: [PATCH] [PR24021] Implement PLUS_EXPR range-op entry for floats.
This is the range-op entry for floating point PLUS_EXPR. It's the
most intricate range entry we have so far, be
On Tue, Nov 8, 2022 at 12:07 PM Jakub Jelinek wrote:
>
> On Mon, Nov 07, 2022 at 04:38:29PM +0100, Aldy Hernandez wrote:
> > From d214bcdff2cb90ad1eb808d29bda6fb98d510b4c Mon Sep 17 00:00:00 2001
> > From: Aldy Hernandez
> > Date: Mon, 7 Nov 2022 14:18:57 +0100
> > Subject: [PATCH] Provide normal
On Mon, Nov 07, 2022 at 04:41:23PM +0100, Aldy Hernandez wrote:
> As suggested upthread, I have also adjusted update_nan_sign() to drop
> the NAN sign to VARYING if both operands are NAN. As an optimization
> I keep the sign if both operands are NAN and have the same sign.
For NaNs this still rel
On Mon, Nov 07, 2022 at 04:38:29PM +0100, Aldy Hernandez wrote:
> From d214bcdff2cb90ad1eb808d29bda6fb98d510b4c Mon Sep 17 00:00:00 2001
> From: Aldy Hernandez
> Date: Mon, 7 Nov 2022 14:18:57 +0100
> Subject: [PATCH] Provide normalized and denormal format version of
> real_isdenormal.
>
> Imple
sign() to drop
the NAN sign to VARYING if both operands are NAN. As an optimization
I keep the sign if both operands are NAN and have the same sign.
How's this?
Tested on x86-64 Linux. LAPACK testing as well.
Aldy
From 7717ad5c495934ff28ea2abd639ab4d91b7ffcab Mon Sep 17 00:00:00 2001
Fro
Fair enough.
How's this?
Tested on x86-64 Linux. LAPACK regression testing as well.
On Mon, Nov 7, 2022 at 1:56 PM Jakub Jelinek wrote:
>
> On Mon, Nov 07, 2022 at 01:48:28PM +0100, Aldy Hernandez wrote:
> > On Mon, Nov 7, 2022 at 1:43 PM Jakub Jelinek wrote:
> > >
> > > On Mon, Nov 07, 2022
On Mon, Nov 07, 2022 at 01:48:28PM +0100, Aldy Hernandez wrote:
> On Mon, Nov 7, 2022 at 1:43 PM Jakub Jelinek wrote:
> >
> > On Mon, Nov 07, 2022 at 01:35:35PM +0100, Aldy Hernandez wrote:
> > > Let me see if I understand you correctly...
> > >
> > > real_isdenormal is always returning false for
On Mon, Nov 7, 2022 at 1:43 PM Jakub Jelinek wrote:
>
> On Mon, Nov 07, 2022 at 01:35:35PM +0100, Aldy Hernandez wrote:
> > Let me see if I understand you correctly...
> >
> > real_isdenormal is always returning false for our uses in frange? So
> > instead of using real_isdenormal in flush_denorm
On Mon, Nov 07, 2022 at 01:35:35PM +0100, Aldy Hernandez wrote:
> Let me see if I understand you correctly...
>
> real_isdenormal is always returning false for our uses in frange? So
> instead of using real_isdenormal in flush_denormals_to_zero, perhaps
> we should be using:
>
> REAL_EXP (r) < R
On Fri, Nov 4, 2022 at 8:53 PM Jakub Jelinek wrote:
>
> On Fri, Nov 04, 2022 at 08:14:23PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > One thing that is clear is that real_isdenormal is never true for these
> > (but then a question is if flush_denormals_to_zero actually works).
>
> So, after s
On Fri, Nov 04, 2022 at 08:14:23PM +0100, Jakub Jelinek via Gcc-patches wrote:
> One thing that is clear is that real_isdenormal is never true for these
> (but then a question is if flush_denormals_to_zero actually works).
So, after some more investigation, I think that is actually the case,
real_
On Mon, Oct 17, 2022 at 08:21:01AM +0200, Aldy Hernandez wrote:
> +// Set VALUE to its next real value, or INF if the operation overflows.
> +
> +inline void
> +frange_nextafter (enum machine_mode mode,
> + REAL_VALUE_TYPE &value,
> + const REAL_VALUE_TYPE &inf)
> +{
> +
On Mon, Oct 17, 2022 at 08:21:01AM +0200, Aldy Hernandez wrote:
> --- a/gcc/range-op-float.cc
> +++ b/gcc/range-op-float.cc
> @@ -200,6 +200,116 @@ frelop_early_resolve (irange &r, tree type,
> && relop_early_resolve (r, type, op1, op2, rel, my_rel));
> }
>
> +// If R contains a NAN of u
Ping ping
On Mon, Oct 24, 2022, 08:04 Aldy Hernandez wrote:
> PING
>
> On Mon, Oct 17, 2022 at 8:21 AM Aldy Hernandez wrote:
> >
> > On Thu, Oct 13, 2022 at 7:57 PM Jakub Jelinek wrote:
> > >
> > > On Thu, Oct 13, 2022 at 02:36:49PM +0200, Aldy Hernandez wrote:
> > > > +// Like real_arithmetic
On 10/24/22 00:04, Aldy Hernandez via Gcc-patches wrote:
PING
I'd be a lot more comfortable if Jakub would chime in here.
Jeff
PING
On Mon, Oct 17, 2022 at 8:21 AM Aldy Hernandez wrote:
>
> On Thu, Oct 13, 2022 at 7:57 PM Jakub Jelinek wrote:
> >
> > On Thu, Oct 13, 2022 at 02:36:49PM +0200, Aldy Hernandez wrote:
> > > +// Like real_arithmetic, but round the result to INF if the operation
> > > +// produced inexact resu
what real_nextafter is doing in those cases,
> I'm afraid it doesn't handle it correctly but the only other use
> of real_nextafter is guarded with:
> /* Don't handle composite modes, nor decimal, nor modes without
> inf or denorm at least for now. */
> if (
On Thu, Oct 13, 2022 at 3:52 PM Toon Moene wrote:
>
> It was just a comment on the code of the PR ...
Ahh... the patch adds support for ranger handling of floating point
PLUS_EXPRs in the IL. The PR's testcase is just one of the many
things it will be able to solve.
Aldy
>
> Toon.
>
> On 10/13
On Thu, Oct 13, 2022 at 02:36:49PM +0200, Aldy Hernandez wrote:
> +// Like real_arithmetic, but round the result to INF if the operation
> +// produced inexact results.
> +//
> +// ?? There is still one problematic case, i387. With
> +// -fexcess-precision=standard we perform most SF/DFmode arithm
It was just a comment on the code of the PR ...
Toon.
On 10/13/22 15:44, Aldy Hernandez wrote:
I'm not following. My patch doesn't affect this behavior.
What am I missing?
Aldy
On Thu, Oct 13, 2022 at 3:04 PM Toon Moene wrote:
On 10/13/22 14:36, Aldy Hernandez via Gcc-patches wrote:
I'm not following. My patch doesn't affect this behavior.
What am I missing?
Aldy
On Thu, Oct 13, 2022 at 3:04 PM Toon Moene wrote:
>
> On 10/13/22 14:36, Aldy Hernandez via Gcc-patches wrote:
>
> > PR tree-optimization/24021
>
> Ah - Verboten in Fortran:
>
> $ cat d.f
>DOUBLE PR
On 10/13/22 14:36, Aldy Hernandez via Gcc-patches wrote:
PR tree-optimization/24021
Ah - Verboten in Fortran:
$ cat d.f
DOUBLE PRECISION A, X
A = 0.0
DO X = 0.1, 1.0
A = A + X
ENDDO
END
$ gfortran d.f
d.f:3:9:
3 | DO X = 0.1, 1.0
[Jakub, this is a cleaned up version of what we iterated on earlier
this summer. It contains additional smarts to propagate NAN signs on
entry. I'd like a nod before committing.]
This is the range-op entry for floating point PLUS_EXPR. It's the
most intricate range entry we have so far, because
37 matches
Mail list logo
