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
