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? Thanks, Alex > > But this function probably isn't hot enough for that to matter. > > Richard
