Martin Sebor <msebor@xxxxxxxxx> writes: > 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. 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.
