Alex Coplan <[email protected]> writes: > On 08/06/2026 14:53, Richard Sandiford wrote: >> Alex Coplan <[email protected]> writes: >> > The PR showed us ICEing in build_poly_int_cst because we have type set >> > to a non-type tree node (a var_decl). A closer look shows this is >> > because we pass the wrong variable to wide_int_to_tree in >> > expmed.cc:make_tree: we pass t instead of type, where t is >> > uninitialized at the point of the call. Fixed thusly. >> >> Thanks for the fix. >> >> > I also took the opportunity to move the CONST_POLY_INT case out of the >> > default: section into its own case of the switch. >> >> FWIW, the reason for generally preferring "CONST_POLY_INT_P (...)" over >> "case POLY_INT_CST:" was so that it would be compiled out on x86 and other >> targets that don't use POLY_INT: >> >> /* Return true if NODE is a POLY_INT_CST. This is only ever true on >> targets with variable-sized modes. */ >> #define POLY_INT_CST_P(NODE) \ >> (NUM_POLY_INT_COEFFS > 1 && TREE_CODE (NODE) == POLY_INT_CST) > > Ah, I see, I did wonder if there was a reason it was done like that. > Would you prefer if I dropped that part of the patch, then? Or is it OK > as is from your POV?
No, it's fine as-is as far as I'm concerned. Richard
