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

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Mar 19 13:36:00 GMT 2015


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
I do think that the gimplifiers "folding" is premature.  All propagators know
to apply the trick internally.  This premature folding is probably to avoid
regressions with removing the invalid maybe_fold_* stuff.

I'll see whether removing it is safe.  Of course it won't fix the testcase
on its own - CCP happily applies the same trick to forward the "constant"
address to the builtin call:

--- t.c.028t.copyrename1        2015-03-19 12:52:53.875179949 +0100
+++ t.c.029t.ccp1       2015-03-19 12:52:53.876179961 +0100
@@ -25,21 +25,15 @@
   struct A a;
   const char * str1.0_2;
   const char * _3;
-  char * _4;
-  int _7;
-  long unsigned int _8;
   char * _9;

   <bb 2>:
   str1.0_2 = str1;
   _3 = str1.0_2 + 5;
-  _4 = &a.buf1 + 4;
-  _8 = __builtin_object_size (_4, 1);
-  _9 = __builtin___strcpy_chk (_4, _3, _8);
+  _9 = __builtin___strcpy_chk (&MEM[(void *)&a + 4B], _3, 6);

also folding the object-size call at the same time (to the bogus value
because of passing it &MEM[(void *)&a, +4B] as well).

I think it is desirable to fold the object-size call here and we can certainly
special-case this particular case (looking at the def of _4 instead of its
lattice value).  But not sure if that's a good enough fix for the general
issue.

After "fixing" the gimplifier we have to make sure neither CCP1, CCP2 or FRE1
perform this trick (forwprop would also wreck things for slightly more
complicated cases).



More information about the Gcc-bugs mailing list