PATCH RFC: gcc 4.1 extern inline patch, take 2

[Joseph S. Myers]

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

> 6) In gcc 4.3 and above, use c99 semantics for "extern inline" in
>    gnu89 and c99 modes.

I hope you mean gnu99, not gnu89.  As I noted we've documented since 2001 
that gnu89 will keep the current semantics.

> * If -fgnu89-extern-inline is used, or if none of -std=c99, -std=gnu99
>   or -fno-gnu89-extern-inline is used, define
>   __GNUC_GNU_EXTERN_INLINE__.  Otherwise, define
>   __GNUC_STDC_EXTERN_INLINE__.

I do not think we need to support -fno-gnu89-extern-inline in c89/gnu89 
modes (and so we shouldn't support it in them, to avoid a proliferation of 
language dialects).

> This patch implements the above proposal for gcc 4.1.  If this is
> accepted, I will follow up with patches for gcc 4.2 and mainline.

Can we get mainline right first and then backport the appropriate subsets 
of the changes and testcases?

> 2007-02-08  Ian Lance Taylor  <iant@google.com>
> 
> 	* c.opt (fgnu89-extern-inline): New option.
> 	* c-opts.c (c_common_handle_option): Give an error for
> 	-fno-gnu89-extern-inline.
> 	* c-common.c (c_common_attribute_table): Add "gnu_inline".
> 	(handle_gnu_inline_attribute): New static function.
> 	* c-decl.c (start_function): In -std=c99 mode, pedwarn about
> 	extern inline.  Support the gnu_inline attribute.
> 	* c-cppbuiltin.c (c_cpp_builtins): Define
> 	__GNUC_GNU_EXTERN_INLINE__.
> 	* toplev.h: If __GNUC_GNU_EXTERN_INLINE or
> 	__GNUC_STD_EXTERN_INLINE is defined, use __attribute__
> 	((gnu_inline)) with inline definitions of floor_log2 and
> 	exact_log2.

Should include doc changes in ChangeLog.

> Index: gcc/doc/extend.texi

The mainline version has gnu_inline in the general list of attributes not 
far above the text you patch.  That part of the docs needs including in 
the backport.

> +either @code{__GNUC_GNU_EXTERN_INLINE__} or
> +@code{__GNUC_STD_EXTERN_INLINE__} are defined.  @xref{Inline,,An

> @@ -3601,6 +3624,17 @@ existing semantics will remain available
>  specified, but eventually the default will be @option{-std=gnu99} and
>  that will implement the C99 semantics, though it does not do so yet.)

This paragraph is the one I pointed out that can be edited for 4.1 and 4.2 
branches - maybe even in 4.1.2 - to state that the C99 semantics apply in 
C99 modes from 4.3 onwards.

> +For convenience in porting programs, GCC automatically defines
> +preprocessor macros to indicate which semantics are being used for
> +@code{extern inline} functions.  @code{__GNUC_GNU_EXTERN_INLINE__}
> +will be defined for the traditional GNU definition (an @code{extern
> +inline} function is like a macro).  @code{__GNUC_STDC_EXTERN_INLINE__}

__GNUC_STD_EXTERN_INLINE__ or __GNUC_STDC_EXTERN_INLINE__?

> +versions before 4.3 do not support C99 @code{extern line} semantics,

extern inline, not extern line.

> +# if defined (__GNUC_GNU_EXTERN_INLINE__) || defined (__GNUC_STDC_EXTERN_INLINE)

Or __GNUC_STDC_EXTERN_INLINE, a third spelling?

> +  /* C99 defined "extern inline" in a way which is incompatible with
> +     the traditional GNU definition of "extern inline".  The C99
> +     definition is supported in gcc 4.3.  */
> +
> +  if (current_extern_inline
> +      && !flag_gnu89_extern_inline
> +      && flag_isoc99
> +      && flag_iso)
> +    pedwarn ("ISO C99 definition of %<extern inline%> is not supported");

I don't really think pedwarn is appropriate; logically it should be 
"sorry" for something not implemented but that's too drastic here, failing 
that "warning" (I still think we shouldn't put this diagnostic on 4.1 
branch at all).

-- 
Joseph S. Myers
joseph@codesourcery.com