Re: C inlines that are also builtins.

[Sergey Organov <sorganov at gmail dot com>]

Marc Glisse <marc.glisse@inria.fr> writes:

> On Tue, 10 Nov 2015, Sergey Organov wrote:
>
>> Martin Sebor <msebor@gmail.com> writes:
>>
>>> On 11/09/2015 12:38 PM, Sergey Organov wrote:
>>>> Martin Sebor <msebor@gmail.com> writes:
>>>>
>>>>> On 11/09/2015 05:57 AM, Sergey Organov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> 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
>>>>>> 'extern'.
>>>>>>
>>>>>> 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:
>>>>>
>>>>>    https://gcc.gnu.org/onlinedocs/gcc/Inline.html
>>>>
>>>> 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.
>>
>> Yeah, freestanding environment is what I care about.
>
> Then you should be using -ffreestanding (which implies -fno-builtin).

Yeah, but I do want nice GCC builtins where possible and I don't want to
track what functions are (currently; on this particular target) GCC
builtins and what are not. Basically, it's a problem of making
environment as close to hosted as possible without supporting all the
required hosted functionality.

Currently, inlines for builtins compile/link fine in -std=c89/gnu89
modes, but break in -std=c99/gnu99/c11/gnu11 modes.

-- Sergey.