Thanks.. Ive incorporated it into my commit  too.

Andrew

On 3/24/23 11:15, Jakub Jelinek wrote:
> On Fri, Mar 24, 2023 at 11:08:54AM -0400, Andrew MacLeod wrote:
>> Before floating point relations were added, we tried to sanitize
>> value-relation records to not include non-sensensical records... ie x != x
>> or x < x.   Instead, we made a VREL_VARYING record with no operands.
>>
>> When floating point relation support was added, some of these were no longer
>> non-sensical, AND we expanded the use of value_relation records into GORI
>> shortly thereafter.
>>
>> As a result, this sanitization is no longer needed, nor desired. The Oracle
>> does not create records with op1 == op2 already, so its only within GORI
>> that these records can exist, and we shouldn't try to interpret them.
>>
>> The bug occurs because the "sanitized" records doesn't set op1 and op2, and
>> changes the relation to VARYING..  and we expected the operands it to be set
>> the way they were specified.  We should not be setting a VREL_VARYING record
>> if asked to set something else.  In fact, we are missing some opportunities
>> because we are trying to FP range-ops that op1 != op1  but its getting
>> transformed into a VREL_VARYING record and not communicated properly.
>>
>> Currently bootstrapping on x86_64-pc-linux-gnu and assuming no regressions,
>> OK for trunk?
>>
>> Andrew
>> commit 1f02961b23976d35b10e2399708c6eb00632f9d6
>> Author: Andrew MacLeod <amacleod@redhat.com>
>> Date:   Fri Mar 24 09:18:33 2023 -0400
>>
>>      Don't interpret contents of a value_relation record.
>>      
>>      before floating point relations were added, we tried to sanitize
>>      value-relation records to not include non-sensensical records... ie
>>      x != x or x < x.   INstead, we made a VREL_VARYING record with no
> s/IN/In/
>
>>      operands.
>>      
>>      When floating point relations were supported, some of these were no
>>      longer non-sensical, AND we expanded the use of value_relation records
>>      into GORI.
>>      
>>      As a result, this sanitization is no longer needed.  The Oracle
>>      does not create records with op1 == op2, so its only within GORI
>>      that these records can exist, and we shouldnt try to interpret them.
> s/shouldnt/shouldn't/
>>      
>>      The bug occurs because the "sanitized" records doesnt set op1 anmd op2,
> s/doesnt/doesn't/
>
>>      but we have a record so expected it to be set.
>>      
>>              PR tree-optimization/109265
>>              PR tree-optimization/109274
>>              gcc/
>>              * value-relation.h (value_relation::set_relation): Always create the
>>              record that is requested.
>>      
>>              gcc/testsuite/
>>              * gcc.dg/pr109274.c: New.
> LGTM, indeed with floating point  a != a isn't nonsensical but basically
> __builtin_isnan (a) check.
>
> I'll commit the Fortran testcase I've added in my version of the patch
> incrementally when you commit.
>
> 	Jakub
>