https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126702
Arsen Arsenović <arsen at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |arsen at gcc dot gnu.org
--- Comment #6 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(In reply to Antonio Diaz Diaz from comment #3)
> Thanks to Drea Pinski for pointing out that rejecting the code below might
> not be a bug in gcc. But I would like to make the point that the code below
> is valid C, that rejecting it is in fact a bug in gcc, and that even if it
> is not a bug in gcc, it would be better for the user that gcc reverted to
> the behavior of previous versions of gcc that considered it valid C.
>
> inline int f() { return 0; }
> int main() { return f(); }
>
> The code above contains an inline definition of f. Clause 6.7.4 of the C99
> standard states that "An inline definition provides an alternative to an
> external definition, which a translator may use to implement any call to the
> function in the same translation unit. It is unspecified whether a call to
> the function uses the inline definition or the external definition". Clause
> 3.4.4 defines unspecified behavior as a choice between two or more
> possibilities, and uses as example "the order in which the arguments to a
> function are evaluated". Now, when a function takes exactly one argument,
> there is no choice; the compiler must evaluate the only argument provided.
> Similarly, in the code above, only one definition of f is provided.
> Therefore there is no choice; the compiler must use the only definition
> provided. Thus, the code above is valid C; it does not contain unspecified
> behavior, much less undefined behavior.
this does not follow; the two options are "use the inline definition" or "use
the external definition".
the compiler here picks the latter and emits a reference to a function you
never defined.
either use 'static inline' or provide the definitions in a TU /without/ the
inline keyword once.
> If, for some reason, you consider my interpretation of the C standard
> invalid, I posit that gcc should consider the code above as valid C because
> it is unambiguous, C99 allows it, previous versions of gcc compiled it as
> expected, ...
did they? I don't see how they could've.
note that in C++ inline behaves closer to what you'd like; in C++ inline
definitions are merged into one.
