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 >
