https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 21 Apr 2025, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119792 > > --- Comment #18 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > > So WITH_SIZE_EXPR isn't applicable here? OK, that's a thing > > only introduced by gimplification at the moment, IIRC. So in case > > the VIEW_CONVERT_EXPR is "just" to make the gimplifier emit the > > appropriate WITH_SIZE_EXPR I wonder whether we should change > > GENERIC to make that the prefered communication vehicle? > > No, WITH_SIZE_EXPR is not directly applicable here because the size of the RHS > is not given by the RHS but by the LHS instead (WITH_SIZE_EXPR works when the > size of an expression only depends on itself), hence the need for the > VIEW_CONVERT_EXPR: once it is lost, there is no way to compute the size of the > RHS. So the size is implicitly present by looking at the LHS then? That said, what was the OK stmt we are talking about and when stripping the V_C_E when does it go wrong (and where?) - I suppose during RTL expansion? That said - IMO WITH_SIZE_EXPR is non-GIMPLEish as well, for an aggregate copy we should have a gimple_assign_size (), thus make the size part of the operation. This would be in-line with the idea of allowing same-size operands on assignments or rather making GIMPLE aggregate copies actual block copies (but without the side-effect of address-taking like we have with using memcpy and possibly supporting things like byte-order and address-spaces).
