https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126702
--- Comment #3 from Antonio Diaz Diaz <antonio at gnu dot org> ---
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.
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,
and because a succesful compilation is more user-friendly than a misleading
diagnostic about an "undefined reference to 'f'" when the user clearly supplied
a definition of f in that translation unit and f is not used in any other
translation unit.
Thanks.
