This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Do not transform strchr into rawmemchr
On Thu, 17 Nov 2016, Zack Weinberg wrote:
> Regarding __builtin_strfoo versus strfoo, I _think_ an inline forward to
> __builtin_strfoo does something useful when either the name or the type
> signature of 'strfoo' doesn't match what the compiler expects. So, for
> instance, we will want them in the covariance case as long as the C++
> compiler hasn't had its builtins updated to know that there are now two
> overloads of strwhatever -- but then they become unnecessary. On the
> other hand, in the strchr/rawmemchr case, the basic prototype for strchr
> should be enough to clue the compiler that it knows what this function
> does, with no further prompting. I could be wrong about this.
> cc: Joseph: do you know whether my understanding is accurate?
Mapping strfoo to __builtin_strfoo may also be useful in the case where
strfoo is not a C90 function (so the user may have used -std=c90
-D_GNU_SOURCE, getting the declaration of strfoo but without it being
built-in in the compiler).
In the strchr case, it's a C90 function so aside from inlines for C++
overloads mapping to __builtin_strchr should not be of use (if someone
uses -fno-builtin or -ffreestanding there should be no expectation that
headers need to try to optimize things anyway, and even the case where
-std with feature test macros means the function is declared but not
built-in is pretty marginal).
Joseph S. Myers