Re: [PATCH v2] Remove defines to builtins in string2.h

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 22 Nov 2016, Wilco Dijkstra wrote:

> > I'm surprised to see stpcpy in this patch because the first paragraph 
> > says this change is exclusively about C90 functions, and stpcpy isn't one.
> 
> Joseph's reply to my question made it clear the redirection is done elsewhere
> in most cases, so that means we can remove the redirections of non-C90
> symbols from string2.h as well:

My suggestion for stpcpy included:

  Thus, it should be possible just to call stpcpy directly everywhere in 
  glibc rather than __stpcpy, and rely on those redirections to ensure that 
  the calls actually end up being namespace-clean (but can be inlined if 
  appropriate as GCC knows about stpcpy as a built-in function in gnu11 
  mode).  Then the definition of __stpcpy in bits/string2.h should not be 
  needed for building glibc.

Unless you also change all calls to __stpcpy to call stpcpy directly, you 
are potentially losing built-in function optimizations by removing the 
__stpcpy macro.  glibc contains calls to __stpcpy as well as direct ones 
to stpcpy.  Because of the other redirections, it's safe to change 
__stpcpy calls to stpcpy calls in glibc as a preparatory patch.  Likewise 
__mempcpy.

I think you need to separate the case of

#define foo(x) __builtin_foo (x)

from all the other cases, where a more complicated macro expansion is 
involved (in which case we need to see if GCC has relevant optimizations 
or have a reason why they are appropriate to discard), or where the macro 
is __foo instead of foo.

Also, patches like this are the sort where it would be useful to make sure 
that installed stripped shared libraries and executables are unchanged by 
the patch, or to have a reason why it results in any changes to the 
generated code.

-- 
Joseph S. Myers
joseph@codesourcery.com