This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gnu_inline attribute for C++
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Geoffrey Keating <geoffk at apple dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Mark Mitchell <mark at codesourcery dot com>, Alexandre Oliva <aoliva at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 11 Jul 2007 03:47:03 -0400
- Subject: Re: gnu_inline attribute for C++
- References: <orir9d98gq.fsf@oliva.athome.lsd.ic.unicamp.br> <46943918.9040707@codesourcery.com> <m3ps2zr54s.fsf@localhost.localdomain> <m2fy3vh763.fsf@greed.local>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jul 10, 2007 at 09:54:12PM -0700, Geoffrey Keating wrote:
> Ian Lance Taylor <iant@google.com> writes:
>
> > Mark Mitchell <mark@codesourcery.com> writes:
> >
> > > Doesn't something already check that we don't have DECL_INITIAL for both
> > > NEW_RESULT and OLD_RESULT? If we have DECL_INITIAL for both, that means
> > > the function is defined twice, which should be an error. Or does
> > > gnu_inline allow you to override the definition in the same translation
> > > unit? That's a pretty nasty complication. I'm not confident that you
> > > can undo the effects of DECL_INTERFACE_KNOWN and such after the fact, in
> > > the way that you're trying to do.
> >
> > The gnu_inline attribute does permit overriding the definition in the
> > same translation unit. You can see this in action in the gcc sources:
> > compare the definition of floor_log2 in toplev.h and toplev.c.
>
> The C++ language, however, doesn't permit such things, and I doubt
> that the C++ frontend is expecting such things to happen.
The C language doesn't permit that either, that's why it is a GNU extension.
> What happens if you have a structure definition with the same name in
> both functions, and it needs RTTI support?
Whatever we decide as part of defining this extension. Such structure
definitions can be simply not allowed in __attribute__((gnu_inline)) inline
functions (they are meant to be small optimized versions of the full blown
out of line functions after all), required to have different name (this
would be my preference in this case) or must be the same with RTTI info shared.
Similarly for static vars in such inline functions (where my preference
would be they can have the same name as long as they have the same type
in both locations, otherwise have to use a different name).
Jakub