Hi Sergei,
On 11/20/10 4:46 PM, Sergei Golubchik wrote:
> Hi, Davi!
>
> On Nov 20, Davi Arnaut wrote:
>> # At a local mysql-5.1-bugteam repository of davi
>>
>> 3513 Davi Arnaut 2010-11-20
>> Bug#57994: Compiler flag change build error : my_redel.c
>>
>> -#if defined(HAVE_STPCPY)&& MY_GNUC_PREREQ(3, 4)
>> +#if defined(HAVE_STPCPY)&& MY_GNUC_PREREQ(3, 4)&&
> !defined(__INTEL_COMPILER)
>> #define strmov(A,B) __builtin_stpcpy((A),(B))
>> #elif defined(HAVE_STPCPY)
>> #define strmov(A,B) stpcpy((A),(B))
>
> Why do you need to do anything at all for __builtin_stpcpy ?
> I'd expect that if you simply use stpcpy everywhere, the compiler will
> be able to use the builtin if appropriate. Automatically.
>
You are absolutely right, but one of the earlier patches in the bug
report explains what I'm trying to work around:
"The expansion of stpcpy (in glibc) causes warnings if the
return value of strmov is not being used. Since stpcpy is
a GNU extension and the expansion ends up using a built-in
provided by GCC, use the compiler provided built-in directly
when possible. Nonetheless, the C library must have stpcpy
as a call be emitted if the built-in can not optimized."
It's just a hack to avoid some Linux hosts where this expansion causes a
warning. Take a look at the stpcpy definition in
/usr/include/bits/string2.h, where it plays with strlen and etc, some
GCC versions do not like. Since we do debug builds with -Werror by
default now, some things have to be worked around... :|
Regards,
Davi
