Re: c/10488: Implementation of extern inline is exactly backwards

Re: c/10488: Implementation of extern inline is exactly backwards

[bangerth]

Synopsis: Implementation of extern inline is exactly backwards

State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Fri Apr 25 00:57:12 2003
State-Changed-Why:
    This weird "extern inline" thing in gcc predates standardization,
    as far as I know (this is also why glibc uses this stuff).
    Unfortunately, the standard didn't take over gcc 
    semantics, and since glibc uses this we can't just
    switch :-(
    
    I recall that there have been lots of discussions aboutthis on the mailing lists. You will probably find quite
    some material by searching them -- google gives me some
    4230 hits for the combination "extern inline" and gcc.
    
    This is a well-known deficiency in gcc, so I think I can
    close this report.
    
    Wolfgang

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10488

Re: c/10488: Implementation of extern inline is exactly backwards

[Joseph S. Myers]

The following reply was made to PR c/10488; it has been noted by GNATS.

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: David.Moore@intel.com
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: c/10488: Implementation of extern inline is exactly backwards
Date: Fri, 25 Apr 2003 09:36:13 +0100 (BST)

 On Fri, 25 Apr 2003 David.Moore@intel.com wrote:
 
 > When extern inline is used on a function definition, a body for that
 > function must be layed down in the current compilation unit binary. When
 > just inline is given, no body should be layed down.
 
 We are aware of this.  See c99status.html.  The intention is that for
 compatibility the existing semantics will remain in gnu89 mode and the C99
 semantics will be provided in c99/gnu99 modes.  Patches to implement the
 C99 semantics (including the necessary fixincludes work to fix the many
 different versions of installed glibc headers that expect the old
 semantics, and including thorough testcases) are welcome; I am not aware
 of anyone working on this.
 
 > 6.7.4 says that if all the declarations of a function are "inline" (not
 > "extern inline") the compilation unit does not provide an external
 > definition for the function. That is, the body is not layed down.
 > Otherwise, if the extern storage class specifier is used, a body must be
 > layed down as per section 6.9.
 
 And note this means it is not as simple as:
 
 > Fix is probably simply a matter of flipping a condition but beware that
 > there are uses of this in the gnu C header files where the usage is
 > believed to also be backwards.
 
 (apart from the need to condition on flag_isoc99) because, for example, a
 function can be defined inline (without extern) and a subsequent
 declaration (as extern or without inline) then means an external
 definition must be provided.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk

Re: c/10488: Implementation of extern inline is exactly backwards

[Andrew Pinski]

The following reply was made to PR c/10488; it has been noted by GNATS.

From: Andrew Pinski <pinskia@physics.uc.edu>
To: David.Moore@intel.com
Cc: Andrew Pinski <pinskia@physics.uc.edu>, gcc-gnats@gcc.gnu.org
Subject: Re: c/10488: Implementation of extern inline is exactly backwards
Date: Thu, 24 Apr 2003 20:39:41 -0400

 Known bug, look at http://gcc.gnu.org/c99status.html for more 
 information.
 
 "C99 inline functions do not generate an external definition if 
 declared without extern, but do if declared with extern, the opposite 
 of GCC's handling of inline and extern inline.  This will probably 
 require existing glibc headers to be fixincluded."
 
 Thanks,
 Andrew Pinski
 

c/10488: Implementation of extern inline is exactly backwards

[David.Moore]

>Number:         10488
>Category:       c
>Synopsis:       Implementation of extern inline is exactly backwards
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 25 00:36:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     David Moore
>Release:        gcc 3.2 20020903
>Organization:
>Environment:
Red Hat Linux 8.0 3.2.7
>Description:
When extern inline is used on a function definition, a body for that function must be layed down in the current compilation unit binary. When just inline is given, no body should be layed down.

See the C99 standard ISO/EEC 9899:1999.

6.7.4 says that if all the declarations of a function are "inline" (not "extern inline") the compilation unit does not provide an external definition for the function. That is, the body is not layed down. Otherwise, if the extern storage class specifier is used, a body must be layed down as per section 6.9.

However, gcc 3.2 lays down a body when extern is not given and fails to do so when extern is used - exactly the opposite of what is required.

Example code:
===========================
#include <stdio.h>
EXTERNAL inline lay_me_down_maybe(int i) {return i*i+2;}
int main () {return lay_me_down_maybe(42);}

gcc -c -O2 -DEXTERNAL=extern example.c
nm example.o
00000000 T main

gcc -c -O2 -DEXTERNAL= example.c
nm example.o
00000010 T lay_me_down_maybe
00000000 T main




>How-To-Repeat:

>Fix:
Fix is probably simply a matter of flipping a condition but beware that there are uses of this in the gnu C header files where the usage is believed to also be backwards.
>Release-Note:
>Audit-Trail:
>Unformatted: