Re: [PATCH] PR tree-optimization/107985 - Ensure arguments to range-op handler are supported.

[Richard Biener <richard.guenther@gmail.com>]

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).

Otherwise looks straight forward.

Thanks,
Richard.

> Andrew
>