On 12/7/22 12:26, Richard Biener wrote:
> On Wed, Dec 7, 2022 at 5:45 PM Andrew MacLeod via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>> THis patch invalidates a range-op handler object if an operand type in
>> the statement is not supported.
>>
>> This also triggered a check in stmt dependency resolution which assumed
>> there must be a valid handler for any stmt with an appropriate LHS
>> type... which is a false assumption.
>>
>> This should do for now, but long term I will rework the dispatch code to
>> ensure it matches the specifically supported patterns of operands. This
>> will make the handler creation a little slower, but speed up the actual
>> dispatch, especially as we add new range types next release.  Its also
>> much more invasive... too much for this release I think.
>>
>> bootstraps on x86_64-pc-linux-gnu with no regressions.  OK?
> +         if (!Value_Range::supports_type_p (TREE_TYPE (m_op1)) ||
> +             !Value_Range::supports_type_p (TREE_TYPE (m_op2)))
>
> The ||s go to the next line.  Since in a GIMPLE_COND both operand types
> are compatible it's enough to check one of them.
>
> Likewise for the GIMPLE_ASSIGN case I think - I don't know of any
> binary operator that has operands that would not be both compatible
> or not compatible (but it's less clear-cut here).
>
Doh.  Checked this in:

Andrew