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