On Wed, Nov 9, 2022 at 3:58 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Wed, Nov 09, 2022 at 10:02:46AM +0100, Aldy Hernandez wrote:
> > We can implement the op[12]_range entries for plus and minus in terms
> > of each other.  These are adapted from the integer versions.
>
> I think for NANs the op[12]_range shouldn't act this way.
> For the forward binary operations, we have the (maybe/known) NAN handling
> of one or both NAN operands resulting in VARYING sign (maybe/known) NAN
> result, that is the somehow the case for the reverse binary operations too,
> if result is (maybe/known) NAN and the other op is not NAN, op is
> VARYING sign (maybe/known) NAN, if other op is (maybe/known) NAN,
> then op is VARYING sign maybe NAN (always maybe, never known).
> But then for + we have the -INF + INF or vice versa into NAN, and that
> is something that shouldn't be considered.  If result isn't NAN, then
> neither operand can be NAN, regardless of whether result can be
> +/- INF and the other op -/+ INF.

Heh.  I just ran into this while debugging the problem reported by Xi.

We are solving NAN = op1 - VARYING, and trying to do it with op1 = NAN
+ VARYING, which returns op1 = NAN (incorrectly).

I suppose in the above case op1 should ideally be
[-INF,-INF][+INF,+INF]+-NAN, but since we can't represent that then
[-INF,+INF] +-NAN, which is actually VARYING.  Do you agree?

I'm reverting this patch as attached, while I sort this out.

Thanks.
Aldy