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. Currently, inlines for builtins compile/link fine in -std=c89/gnu89 modes, but break in -std=c99/gnu99/c11/gnu11 modes. -- Sergey.
