Joseph S. Myers - Re: Clean up extern inline (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

• From: "Joseph S. Myers"
• To: Ian Lance Taylor
• Cc: gcc-patches at gcc dot gnu dot org
• Date: Fri, 2 Feb 2007 03:30:29 +0000 (UTC)
• Subject: Re: Clean up extern inline
• References: <m3zm7xnuev.fsf@localhost.localdomain>

On Fri, 1 Feb 2007, Ian Lance Taylor wrote:

• Add option -fgnu-extern-inline which indicates that gnu89 "extern inline" should be used.

We do need such an option in 4.3 and later because Ulrich will not accept Jakub's glibc patch (he'll only accept header fixes but not fixes to the rest of glibc). Adding it to 4.1/4.2 seems reasonable if it makes it more convenient for glibc to use this option.

• If we see an "extern inline" function:
  • If -fgnu-extern-inline is used, apply gnu89 semantics.
  • Else, if the declaration is in a system header, apply gnu89 semantics.
  • Else, if -std=c99 is used, but not -std=gnu99, issue an error.

I'd add that -fno-gnu-extern-inline should be an error in 4.1/4.2, and more generally in c89/gnu89 modes (the number of language dialects should be minimised). But adding any diagnostics for this to 4.1 branch would be a mistake; it would make upgrading from 4.1.2 to 4.1.3 unsafe for some users. (I don't think we should add such deprecation warnings to past release branches once they've had a release from them, at all, ever.)

• If we see an "extern inline" function:
  • If -fgnu-extern-inline is used, apply GNU semantics.
  • Else, apply c99 semantics.

Changing the definition of gnu89 in this regard is wrong, in any version at all. The gnu89 dialect has the defined semantics (in fact, the option should probably be called -fgnu89-extern-inline instead to make it clear that gnu89 semantics are being selected). The future behavior of both gnu89 and gnu99 has been promised in the documentation ever since my patch

2001-05-21 Joseph S. Myers jsm28@cam.ac.uk

    * extend.texi: Clarify documentation of extensions included in ISO
    C99.  Prefer C99 terminology and syntax to old GNU terminology and
    syntax.  Add more index entries.  Document mixed declarations and
    code as an extension in C89 mode.  Warn about future changes to
    semantics of inline functions.  Fixes PR other/930.

added the paragraph:

+For future compatibility with when GCC implements ISO C99 semantics for +inline functions, it is best to use @code{static inline} only. (The +existing semantics will remain available when @option{-std=gnu89} is +specified, but eventually the default will be @option{-std=gnu99} and +that will implement the C99 semantics, though it does not do so yet.)

The rules (for 4.3 and later) should be:

• If !flag_isoc99, gnu89 inline is always used; -fgnu89-extern-inline is a no-op and -fno-gnu89-extern-inline is an error.

• If flag_isoc99, C99 inline is used unless -fgnu89-extern-inline is specified, in which case (a) if flag_iso, there is an error, (b) if !flag_iso, gnu89 inline is used.

• Any preprocessor macro always reflects which inline semantics are in use.

-- Joseph S. Myers joseph@codesourcery.com

• Follow-Ups:
  • Re: Clean up extern inline
    * From: Ian Lance Taylor
  • Re: Clean up extern inline
    * From: Jakub Jelinek
• References:
  • Clean up extern inline
    * From: Ian Lance Taylor