[Bug middle-end/50460] [4.7 Regression] __builtin___strcpy_chk/__builtin_object_size don't work

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-28 12:23:15 UTC ---
Btw, this is equivalent to a missing diagnostic, it's correctly not trapping
similar as to if it didn't know anything about the object that is refered to.

Indeed when I disable the folding during gimplification CCP comes along
and does

 <bb 2>:
   str1.0_1 = str1;
   D.2732_2 = str1.0_1 + 5;
-  D.2733_3 = &a.buf1 + 4;
-  __dest_7 = (char * restrict) D.2733_3;
   __src_8 = (const char * restrict) D.2732_2;
-  D.2747_9 = __builtin_object_size (__dest_7, 1);
-  D.2746_10 = __builtin___strcpy_chk (__dest_7, __src_8, D.2747_9);
-  D.2746_12 = D.2746_10;
-  D.2734_4 = 0;
-  return D.2734_4;
+  D.2746_10 = __builtin___strcpy_chk (&MEM[(void *)&a + 4B], __src_8, 6);
+  return 0;

which is good, as the address is invariant.

So, short of moving the objsize pass way earlier (which I'm sure we don't
want to do), I don't see a good way to recover this diagnostic.

One possibility is to make sure try_move_mult_to_index handles the case
of &a.buf1 + 4, instead of just &a.buf1[0] + 4.  I have a patch for that.