Re: C inlines that are also builtins.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/11/2015 04:58 AM, Sergey Organov wrote:
Marc Glisse <marc.glisse@xxxxxxxx> writes:

On Tue, 10 Nov 2015, Sergey Organov wrote:

Martin Sebor <msebor@xxxxxxxxx> writes:

On 11/09/2015 12:38 PM, Sergey Organov wrote:
Martin Sebor <msebor@xxxxxxxxx> 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.

Does that help?

Martin




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux