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).
