On Wed, Nov 9, 2022 at 11:55 AM Jakub Jelinek <ja...@redhat.com> wrote: > > Hi! > > foperator_abs::op1_range works except for the NaN handling, > from: > [frange] double [-Inf, > 1.79769313486231570814527423731704356798070567525844996599e+308 > (0x0.fffffffffffff8p+1024)] > lhs it computes r > [frange] double > [-1.79769313486231570814527423731704356798070567525844996599e+308 > (-0x0.fffffffffffff8p+1024), > 1.79769313486231570814527423731704356798070567525844996599e+308 > (0x0.fffffffffffff8p+1024)] +-NAN > which is correct except for the +-NAN part. > For r before the final step it makes sure to add -NAN if there is +NAN > in the lhs range, but the final r.union_ makes it unconditional +-NAN, > because the frange ctor sets +-NAN. > So, I think we need to clear it (or have some set variant which > says not to set NAN). > > This patch fixes that, but isn't enough to fix the PR, something in > the assumptions handling is still broken (and the PR has other parts).
LGTM. Sorry I haven't gotten to the PR yet. I'll poke at it later today. Thanks. Aldy > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2022-11-09 Jakub Jelinek <ja...@redhat.com> > > PR tree-optimization/107569 > * range-op-float.cc (foperator_abs::op1_range): Clear NaNs > from the negatives frange before unioning it into r. > > --- gcc/range-op-float.cc.jj 2022-11-06 11:56:27.138137781 +0100 > +++ gcc/range-op-float.cc 2022-11-08 18:13:18.026974667 +0100 > @@ -1280,9 +1280,10 @@ foperator_abs::op1_range (frange &r, tre > return true; > // Then add the negative of each pair: > // ABS(op1) = [5,20] would yield op1 => [-20,-5][5,20]. > - r.union_ (frange (type, > - real_value_negate (&positives.upper_bound ()), > - real_value_negate (&positives.lower_bound ()))); > + frange negatives (type, real_value_negate (&positives.upper_bound ()), > + real_value_negate (&positives.lower_bound ())); > + negatives.clear_nan (); > + r.union_ (negatives); > return true; > } > > > Jakub >
