This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Handling of extern inline in c99 mode


> 
> "Steven Bosscher" <stevenb.gcc@gmail.com> writes:
> 
> > On 11/1/06, Paolo Bonzini <paolo.bonzini@lu.unisi.ch> wrote:
> > >
> > > > According to the proposal, we will restore the GNU handling for
> > > > "extern inline" even when using -std=c99, which will fix the problem
> > > > when using glibc.
> > >
> > > I am probably overlooking something, but if the only problematic system
> > > is glibc, maybe this can be fixed with a fixincludes hack?
> > 
> > That would be a massive hack.
> 
> Indeed.
> 
> Moreover, glibc is not the only problematic system.  gcc historically
> supported "extern inline" long before c99 existed, and there is plenty
> of existing code which uses gcc's definition.  I believe that we need
> to give that code a decent chance to change before we switch over to
> c99.  That is why I recommended adding warnings to all active
> branches, and postponing the changed behaviour of "extern inline" to
> gcc 4.4.

In the 4.3 timeframe, can we also add a flag to enable the correct behavior?
Yes the problem with this is that we have to support this flag for a long time
but the benifit is that we can change the default to the new way with just flipping
a switch.

Also it would be nice to have an attribute or a new keyword to get the old "extern
inline" behavior, something like __extern_but_inline?  Or is there a real equavilant
with C99 style inling (I have not followed this part close enough to figure that out).

Thanks,
Andrew Pinski


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]