RE: c/10489: Implementation of extern inline is exactly backwards

RE: c/10489: Implementation of extern inline is exactly backwards

[Moore, David]

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

From: "Moore, David" <david.moore@intel.com>
To: "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>,
   "'nobody@gcc.gnu.org'" <nobody@gcc.gnu.org>
Cc:  
Subject: RE: c/10489: Implementation of extern inline is exactly backwards
Date: Fri, 25 Apr 2003 10:27:30 -0700

 Oops. On my first attempt to submit this I thought the server had barfed so
 I backed up and resubmitted. As a result there are now two!
 
 My apologies. Please delete one.
 
 -----Original Message-----
 From: gcc-gnats@gcc.gnu.org [mailto:gcc-gnats@gcc.gnu.org] 
 Sent: Thursday, April 24, 2003 5:36 PM
 To: David.Moore@intel.com
 Subject: Re: c/10489: Implementation of extern inline is exactly backwards
 
 Thank you very much for your problem report.
 It has the internal identification `c/10489'.
 The individual assigned to look at your
 report is: unassigned. 
 
 >Category:       c
 >Responsible:    unassigned
 >Synopsis:       Implementation of extern inline is exactly backwards
 >Arrival-Date:   Fri Apr 25 00:36:01 UTC 2003

Re: c/10489: 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:45:17 2003
State-Changed-Why:
    Duplicate of 10488

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

c/10489: Implementation of extern inline is exactly backwards

[David.Moore]

>Number:         10489
>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:01 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: