C inlines that are also builtins.
Tue Nov 10 03:57:00 GMT 2015
On 11/09/2015 12:38 PM, Sergey Organov wrote:
> Martin Sebor <email@example.com> writes:
>> On 11/09/2015 05:57 AM, Sergey Organov wrote:
>>> GCC, when compiling C code, seems to always generate out-of-line copy of
>>> any [C99] inline function that also happens to be a GCC builtin,
>>> resulting in link errors (see a test-case below). According to C99
>>> standard, an out-of-line copy of a function should only be instantiated
>>> in those compilation unit(s) where the function is also declared
>>> Apparently, all builtin functions implicitly get 'extern' declaration that
>>> forces out-of-line copy of inline function in every compilation unit.
>>> Is it a bug of feature? If the latter, what is the way for a library to
>>> provide generic inline functions that might happen to be GCC builtins?
>> Depending on the -std= option, GCC can generate a copy of an inline
>> function (regardless of whether or not the function also has a builtin
>> form) in each translation unit that defines it. To avoid multiple
>> definition errors, define inline functions in C headers as static.
>> The following page explains how GCC treats the inline specifier
>> in each of the standard mode:
> The point is that for builtin functions it apparently does it wrong.
I see. Yes, that does look like a bug. symtab_node::needed_p()
returns false for an ordinary inline function but true for one
that has a builtin. I didn't spend enough time debugging this
to see what sets it and why, and I couldn't find any tests for
this to confirm that it's deliberate.
On the other hand, speaking in the strict C sense, abs and most
(all?) such symbols that have corresponding builtins are reserved
in a hosted implementation so defining them is undefined. They are
only allowed to be defined in a freestanding environment.
In any event, you should probably open a bug so that someone who
knows more about the implementation than I do can say for sure.
More information about the Gcc-help