https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108506
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
>
> Internals of what is going on:
>
> Gimple IR
> bad (__builtin_bit_cast):
> MEM[(struct Foo *)output_7(D) + ivtmp.13_20 * 1] =
> VIEW_CONVERT_EXPR<struct Foo>(_1);
This is an aggregate copy but the RHS is not a load - it's on the border
of invalid^Wunwanted GIMPLE.
> vs good (memcpy):
> MEM <vector(32) unsigned char> [(char * {ref-all})output_7(D) +
> ivtmp.28_20 * 1] = _1;
>
> Both look ok really. Though the first one could be rewritten into the second
> one which would fix the expansion. Though maybe it could be fixed in the
> middle-end while doing the expansion of gimple to RTL.
In other places we said we want V_C_Es on the RHS instead of on the LHS
but here we could consume the V_C_E from the MEM_REF on the LHS since
it's also a nice type to store (beware of extended precision FP types here!).
It's already gimplification / SSA rewrite producing the problematic IL.
