This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]