This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strlen optimizations based on whether stpcpy is declared?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]