[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Inlining `scm_is_pair ()'

From: Ludovic Courtès
Subject: Re: [PATCH] Inlining `scm_is_pair ()'
Date: Wed, 25 Jan 2006 10:21:28 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)


Kevin Ryde <address@hidden> writes:

> Which is probably not really in line with gnu coding standards
> ( end of "Syntactic Conventions" node).  But I guess any
> application might do it.

Certainly not the only thing that's not GCS-compatible in Guile...  ;-)

> That was ceval/deval() local variables on gcc 4 last time I hit that.
> -O1 may be better, or just on eval.c at least.

Right, I don't have the "stack overflow" with `-O1', fortunately.

>> +static SCM_C_INLINE int
> I suspect extern inline is what you want, static inline might end up
> with a copy of the code in every file, under -O0 at least.  But extern
> inline is even more of a gcc-ism, if you're worried about the
> commercial compilers.

With `-O0', no inlining takes place, unless the `always_inline'
attribute was specified.

`extern inline' is a indeed a GCCism.  It might be better since, as you
said, it would allow a single definition to be used in the case where
inlining doesn't take place.  Quoting the GCC manual:

   If you specify both `inline' and `extern' in the function definition,
  then the definition is used only for inlining.  In no case is the
  function compiled on its own, not even if you refer to its address
  explicitly.  Such an address becomes an external reference, as if you
  had only declared the function, and had not defined it.

OTOH, the code of this function is sufficiently small so that code
duplication shouldn't be a concern---if it was, we wouldn't be inlining
in the first place.

So I think it'd make sense to apply it as is.  We'll have to ask people
who work with proprietary compilers to voice out if there's something
wrong anyway.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]