Re: strlen optimizations based on whether stpcpy is declared?

[Alan Modra <amodra at gmail dot com>]

On Mon, Oct 02, 2017 at 09:11:53AM +0200, Jakub Jelinek wrote:
> On Sun, Oct 01, 2017 at 03:52:39PM -0600, Martin Sebor wrote:
> > While debugging some of my tests I noticed unexpected differences
> > between the results depending on whether or not the stpcpy function
> > is declared.  It turns out that the differences are caused by
> > the handle_builtin_strcpy function in tree-ssa-strlen.c testing
> > for stpcpy having been declared:
> > 
> >   if (srclen == NULL_TREE)
> >     switch (bcode)
> >       {
> >       case BUILT_IN_STRCPY:
> >       case BUILT_IN_STRCPY_CHK:
> >       case BUILT_IN_STRCPY_CHKP:
> >       case BUILT_IN_STRCPY_CHK_CHKP:
> > 	if (lhs != NULL_TREE || !builtin_decl_implicit_p (BUILT_IN_STPCPY))
> > 	  return;
> > 
> > and taking different paths depending on whether or not the test
> > succeeds.
> > 
> > As far as can see, the tests have been there since the pass was
> > added, but I don't understand from the comments in the file what
> > their purpose is or why optimization decisions involving one set
> > of functions (I think strcpy and strcat at a minimum) are based
> > on whether another function has been declared or not.
> > 
> > Can you explain what they're for?
> 
> The reason is that stpcpy is not a standard C function, so in non-POSIX
> environments one could have stpcpy with completely unrelated prototype
> used for something else.  In such case we don't want to introduce stpcpy
> into a TU that didn't have such a call.  So, we use the existence of
> a matching prototype as a sign that stpcpy can be synthetized.

Why is the test for stpcpy being declared done for the strcpy cases
rather than the stpcpy cases?

-- 
Alan Modra
Australia Development Lab, IBM