https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- So, given that you promoted this to P1, what are we going to do with this? This indeed started with r214941, and from objsz POV, in *.original, while it changed from: - strcpy (&a.buf1[4], str1 + 5); + strcpy ((char *) &a.buf1 + 4, str1 + 5); it is still reasonable, no information is lost. The information is lost during gimplification, where we gimplify it as: - strcpy (&a.buf1[4], D.1762); + strcpy (&MEM[(void *)&a + 4B], D.1762); and there we already lost the info whether it was strcpy (&a.buf1 + 4, ...) or strcpy (&a, ...), where we really don't want to treat those two the same. So, either we should avoid folding this to a MEM_REF before objsz pass, or allow MEM_REF operand to be (perhaps just before objsz pass) not just SSA_NAME or ADDR_EXPR of a DECL, but also ADDR_EXPR of handled_component_p and only lower it later (lose the information on where it pointed to). Or add optional third argument to MEM_REF that would contain say the COMPONENT_REF (if any) with PLACEHOLDER_EXPR inside for the type of the DECL in ADDR_EXPR in the first operand. Something else?
