On Tue, 28 Feb 2017, Jeff Law wrote: > On 02/28/2017 05:59 AM, Prathamesh Kulkarni wrote: > > On 28 February 2017 at 15:40, Jakub Jelinek <ja...@redhat.com> wrote: > > > On Tue, Feb 28, 2017 at 03:33:11PM +0530, Prathamesh Kulkarni wrote: > > > > Hi, > > > > The attached patch adds special-casing for strcpy/strncpy to dse pass. > > > > Bootstrapped+tested on x86_64-unknown-linux-gnu. > > > > OK for GCC 8 ? > > > > > > What is special on strcpy/strncpy? Unlike memcpy/memmove/memset, you > > > don't > > > know the length they store (at least not in general), you don't know the > > > value, all you know is that they are for the first argument plain store > > > without remembering the pointer or anything based on it anywhere except in > > > the return value. > > > I believe stpcpy, stpncpy, strcat, strncat at least have the same > > > behavior. > > > On the other side, without knowing the length of the store, you can't > > > treat > > > it as killing something (ok, some calls like strcpy or stpcpy store at > > > least > > > the first byte). > > Well, I assumed a store to dest by strcpy (and friends), which gets > > immediately freed would count > > as a dead store since free would kill the whole memory block pointed > > to by dest ? > Yes. But does it happen often in practice? I wouldn't mind exploring this > for gcc-8, but I'd like to see real-world code where this happens.
Actually I don't mind for "real-world code" - the important part is that I believe it's reasonable to assume it can happen from some C++ abstraction and optimization. Richard.
