This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How should __attribute__ ((gnu_inline)) behave?
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 14 Feb 2007 15:28:44 +0100
- Subject: Re: How should __attribute__ ((gnu_inline)) behave?
- References: <m3ps8dzdfu.fsf@localhost.localdomain>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Feb 13, 2007 at 06:21:41PM -0800, Ian Lance Taylor wrote:
> Should __attribute__ ((gnu_inline)) be treated the same as a gnu89
> extern inline definition? Or should the extern part be optional?
> That is, should there be a difference between these two definitions?
>
> extern __attribute__ ((gnu_inline)) inline int foo () { return 0; }
> __attribute__ ((gnu_inline)) inline int foo () { return 0; }
The gnu_inline attribute was meant to be a modifier for the inline
keyword, that would make it behave with GNU89 inline semantics.
So, extern __attribute__ ((gnu_inline)) inline int foo () { return 0; }
in -std=gnu99 mode is exactly the same as extern inline int foo () { return 0; }
in -std=gnu89 mode, similarly for
__attribute__ ((gnu_inline)) inline int foo () { return 0; } in -std=gnu99
vs. inline int foo () { return 0; } in -std=gnu89, etc.
The gnu_inline attribute should e.g. allow adding:
#define inline inline __attribute__ ((gnu_inline))
getting the same inline behavior as -std=gnu89 code (unless you #undef
it).
The testsuite/gcc.dg/inline-17.c testcase already verifies this.
Jakub