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
On Tue, Nov 8, 2022 at 2:50 PM Jakub Jelinek wrote:
>
> 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, co
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
>
On Tue, Nov 8, 2022 at 12:20 PM Jakub Jelinek 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 sign if both o
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
On Fri, Nov 4, 2022 at 8:14 PM Jakub Jelinek wrote:
>
> 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_
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
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 results.
> > +//
> > +// ?? There is still one problematic case, i387. With
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
36 matches
Mail list logo
