Bernd Roesch wrote:
> Hi,
>
> I find this mails here
>
> http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
>
> But i find no answer how i can do same as extern inline and get no problems
> in C99 mode and other modes
http://gcc.gnu.org/ml/gcc/2007-03/msg01093.html
cheers,
DaveK
Hi,
I find this mails here
http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
But i find no answer how i can do same as extern inline and get no problems
in C99 mode and other modes
I use for longer functions this code
extern __inline long func()
{
}
but when a makefile set -std=c99 then get li
I'm not subscribed to this list, I just noticed this discussion
while browsing around... Don't know if the list accept
non-subscriber messages either, but let's see:
Ian Lance Taylor wrote:
> codesearch.google.com finds about 6000 uses of "extern line" in
> code written in C, but the search
>
On Wed, Nov 01, 2006 at 03:05:33PM -0800, Mark Mitchell wrote:
> I think it would be better to have GLIBC changed before changing the
> behavior of the compiler. It might even be better to have a released
> version of GLIBC with the changes. fixincludes causes sufficient
> problems for people
On Wed, Nov 01, 2006 at 08:02:55AM -0800, Ian Lance Taylor wrote:
> 1) Implement a function attribute which is the equivalent of "extern
>inline". Backport support for this attribute to all open branches.
>Try to persuade the glibc developers to use this feature instead of
>"extern inl
On Wed, 1 Nov 2006, Andrew Pinski wrote:
> 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 th
Joseph S. Myers wrote:
On Wed, 1 Nov 2006, Ian Lance Taylor 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.
We definitely need to revert that until the fixincludes changes are
availa
On Wed, 1 Nov 2006, Ian Lance Taylor 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.
We definitely need to revert that until the fixincludes changes are
available. (The precise na
Andrew Pinski <[EMAIL PROTECTED]> writes:
> 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 swi
>
> "Steven Bosscher" <[EMAIL PROTECTED]> writes:
>
> > On 11/1/06, Paolo Bonzini <[EMAIL PROTECTED]> 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.
> > >
>
On Nov 1, 2006, at 10:48 AM, Steven Bosscher wrote:
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.
Yes, fixincludes is a massive hack. Yes, it should not exist. But,
let's k
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> On 11/1/06, Paolo Bonzini <[EMAIL PROTECTED]> 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 ov
On Wed, 1 Nov 2006, Daniel Jacobowitz wrote:
> On Wed, Nov 01, 2006 at 06:59:42PM +, Joseph S. Myers wrote:
> > I'd rather simply fix glibc to work with C99 inline semantics. For the
> > above you might use
> >
> > #define tolower(c) __tolower_inline(c)
> > static __inline __attribute__((__
On Wed, Nov 01, 2006 at 06:59:42PM +, Joseph S. Myers wrote:
> I'd rather simply fix glibc to work with C99 inline semantics. For the
> above you might use
>
> #define tolower(c) __tolower_inline(c)
> static __inline __attribute__((__always_inline__)) int tolower_inline ...
>
> and #undef t
On Wed, 1 Nov 2006, Ian Lance Taylor wrote:
> glibc uses "extern inline", and exploits the traditional gcc ability
> to override the "extern inline" function with a regular function. For
> example, the definition of tolower in is:
>
> extern __inline int
> __NTH (tolower (int __c))
> {
> retu
On 11/1/06, Paolo Bonzini <[EMAIL PROTECTED]> 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, may
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?
Paolo
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
Ian Lance Taylor wrote:
Here is a review followed by a proposal.
How does this proposal handle the current problematic situation that
-std=c99 is broken on Linux?
According to the proposal, we will restore the GNU handling f
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>
> > Here is a review followed by a proposal.
>
> How does this proposal handle the current problematic situation that
> -std=c99 is broken on Linux?
According to the proposal, we will restore the GNU handling for
"extern inli
Ian Lance Taylor wrote:
Here is a review followed by a proposal.
How does this proposal handle the current problematic situation that
-std=c99 is broken on Linux?
We could either revert Geoff's patch, or conditionalize it on Linux.
I'd argue against the latter approach (which is what I bel
[ Moved from gcc-patches@ to [EMAIL PROTECTED] ]
Andrew Pinski <[EMAIL PROTECTED]> writes:
> On Tue, 2006-10-31 at 21:34 -0800, Geoffrey Keating wrote:
> > Here's the list of log (and therefore ChangeLog) entries. There is
> > one change that I haven't merged yet, Caroline's pubtypes changes;
21 matches
Mail list logo
