Re: C inlines that are also builtins.

[Sergey Organov <sorganov at gmail dot com>]

Martin Sebor <msebor@gmail.com> writes:

> On 11/11/2015 04:58 AM, Sergey Organov wrote:
>> 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.
>
> If I understand correctly it sounds to me like what you're looking
> for is the opposite of what I requested in bug 59219 in a slightly
> different context. By defining a function like memcpy inline and
> in terms of __builtin__memcpy_chk GCC expands it inline when it
> can even when -fno-builtin is used. The bug suggests to change
> it but since it's not been implemented (yet) and may never be it
> should be possible to rely on the current behavior.

Dunno if it's opposite or not as I don't quite understand you case. Most
probably it's ortogonal to what I need.

I need to be able to port particular code that works with -std=gnu89
compilation mode to -std=gnu99 or -std=gnu11. This code uses its own
implementation of libc/libm that heavily uses "extern inline" for
standard functions. Right now this task seems to be close to
imopossible, as GCC builtins are always (implicitly) declared as if
-std=gnu89 mode were active. I.e., builtins seem to implicitly get
"extern inline" declaration, while in -std=gnu99 and above modes they
rather should be declared "inline".

-- Sergey.