> I'm displeased with someone's workaround for decisions made by
> the (rather weak) inliner in gcc 3.[123]. In particular, that
> someone doesn't understand all of the implications of always_inline.
...
> In the Alpha port I have a number of places in which I have
> functions that I would like inlined when they are called directly,
> but I also need to take their address so that they may be registered
> as part of a dispatch vector for the specific machine model.
>
> This scheme fails because my functions got marked always_inline
> behind my back, which means they didn't get emitted in the right
> place.
If it hurts, don't do that. It looks like bloat anyway.
Are benchmarks significantly affected if you remove the inline?
If so, simply have a second function:
extern void uninline_foo(void);
...
void uninline_foo(void)
{
foo();
}
> Rather than fight the unwinnable fight to remove this hack entirely,
> may I ask that at least one of the different names for inline, e.g.
> __inline__, be left un-touched so that it can be used by those that
> understand what the keyword is supposed to mean?
>
> Of course, there does not exist a variant that isn't used by all
> sorts of random code, so presumably all existing occurences would
> have to get renamed to plan "inline" in order to keep people happy..
Hey, I argued for INLINE when the static/extern changes
came along. That's the sanest, because one never knows
what the next annoying compiler will demand. Then you
can have one of:
#define INLINE
#define INLINE inline
#define INLINE static inline // an oxymoron
#define INLINE extern inline // an oxymoron
#define INLINE __force_inline
#define INLINE __attribute__((always_inline))
#define INLINE _Pragma("inline")
#define INLINE __inline_or_die_you_foul_compiler
#define INLINE _Please inline
On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> #define INLINE
> #define INLINE inline
> #define INLINE static inline // an oxymoron
> #define INLINE extern inline // an oxymoron
> #define INLINE __force_inline
> #define INLINE __attribute__((always_inline))
> #define INLINE _Pragma("inline")
> #define INLINE __inline_or_die_you_foul_compiler
> #define INLINE _Please inline
The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
will cause spurious ignorance of the remainder of the line, which is
often very important. e.g.
static INLINE int lock_need_resched(spinlock_t *lock)
{
...
-- wli
On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> Are benchmarks significantly affected if you remove the inline?
The routines in question expand to exactly one instruction.
r~
On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
> > #define INLINE static inline // an oxymoron
...
> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
> will cause spurious ignorance of the remainder of the line, which is
> often very important. e.g.
>
> static INLINE int lock_need_resched(spinlock_t *lock)
No it won't. Comments are removed in translation phase 3;
macros are expanded in translation phase 4.
r~
On Thu, 2004-09-23 at 12:50, William Lee Irwin III wrote:
> On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> > #define INLINE
> > #define INLINE inline
> > #define INLINE static inline // an oxymoron
> > #define INLINE extern inline // an oxymoron
> > #define INLINE __force_inline
> > #define INLINE __attribute__((always_inline))
> > #define INLINE _Pragma("inline")
> > #define INLINE __inline_or_die_you_foul_compiler
> > #define INLINE _Please inline
>
> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
Once you get over the initial jolt of seeing new syntax,
you'll find that C99 comments are clearly superior.
Even with block comments above functions, you'll typically
save two lines of screen space. (and 7 bytes)
I think the only trouble is assembly code abusing
the C (note: "C", not "assembly") pre-processor.
> will cause spurious ignorance of the remainder of the line, which is
> often very important. e.g.
>
> static INLINE int lock_need_resched(spinlock_t *lock)
> {
Huh? Sure? It works for me:
albert 0 /tmp$ cat slash.c
#define MAIN main // test C99 comment
int MAIN (int argc, char *argv[]){
(void)argc;
(void)argv;
return 0;
}
albert 0 /tmp$ gcc -Wall -W -O2 slash.c
albert 0 /tmp$ ./a.out
albert 0 /tmp$ gcc -v
Reading specs from /usr/lib/gcc-lib/powerpc-linux/3.2.3/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc powerpc-linux
Thread model: posix
gcc version 3.2.3 20030415 (Debian prerelease)
On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
> > #define INLINE static inline // an oxymoron
>
> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
> will cause spurious ignorance of the remainder of the line, which is
Usual Albert's taste level aside, you are wrong. Comments are replaced
with whitespace on phase 3 (tokenizer) and preprocessor lives on phase 4.
IOW, that // will never be seen by preprocessor.
On Thu, Sep 23, 2004 at 10:33:15AM -0700, William Lee Irwin III wrote:
> On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
> >> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
> >> will cause spurious ignorance of the remainder of the line, which is
>
> On Thu, Sep 23, 2004 at 06:21:04PM +0100, [email protected] wrote:
> > Usual Albert's taste level aside, you are wrong. Comments are replaced
> > with whitespace on phase 3 (tokenizer) and preprocessor lives on phase 4.
> > IOW, that // will never be seen by preprocessor.
>
> I'll be sure to put this on file with the rest of the numerous "while
> legal in C, never *EVER* do this" oddities.
Huh? Comments (all sorts of comments) are dealt with before you get to
preprocessing. Which *is* the right behaviour - anything else would be
much, much messier. What's the problem with that?
On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
>> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
>> will cause spurious ignorance of the remainder of the line, which is
On Thu, Sep 23, 2004 at 06:21:04PM +0100, [email protected] wrote:
> Usual Albert's taste level aside, you are wrong. Comments are replaced
> with whitespace on phase 3 (tokenizer) and preprocessor lives on phase 4.
> IOW, that // will never be seen by preprocessor.
I'll be sure to put this on file with the rest of the numerous "while
legal in C, never *EVER* do this" oddities.
-- wli
On Thu, 2004-09-23 at 12:54, Richard Henderson wrote:
> On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> > Are benchmarks significantly affected if you remove the inline?
>
> The routines in question expand to exactly one instruction.
Fine, but that's not what I asked.
I asked if it shows up on benchmarks. It doesn't, does it?
Supposing that it does, then you might use the
alternate instruction replacement trick for this.
That will beat function pointers for speed.
Also, a simple conditional branch might be better
predicted than a function pointer anyway. At least
it will be close.
So you have at least four reasonable choices:
a. don't inline at all
b. have an uninline_foo() version for each foo
c. instruction replacement
d. simple conditional
The simple choices are better, unless you have
benchmarks (whole system ones) that show otherwise.
Salut,
On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
> On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> > #define INLINE static inline // an oxymoron
> > #define INLINE extern inline // an oxymoron
>
> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
> will cause spurious ignorance of the remainder of the line, which is
> often very important. e.g.
>
> static INLINE int lock_need_resched(spinlock_t *lock)
> {
> ...
Mmm, shouldn't the comments be filtered *before* the definition is set
in place? Just wondering...
Tonnerre
On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
>>> #define INLINE static inline // an oxymoron
>>> #define INLINE extern inline // an oxymoron
On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
>> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
>> will cause spurious ignorance of the remainder of the line, which is
>> often very important. e.g.
>> static INLINE int lock_need_resched(spinlock_t *lock)
>> {
>> ...
On Sun, Sep 26, 2004 at 03:29:25AM +0200, Tonnerre wrote:
> Mmm, shouldn't the comments be filtered *before* the definition is set
> in place? Just wondering...
I've already heard more about this than I ever cared to. I'll continue
to stick to saner subsets of C and refuse to use things such as how the
preprocessor committing incest with the compiler proper (no, I don't
need it explained to me, it's trivial) allows crappy code to be written.
Don't lecture me; there's nothing to explain and I don't want to hear it.
-- wli
William Lee Irwin III wrote:
> On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
>
>>>>#define INLINE static inline // an oxymoron
>>>>#define INLINE extern inline // an oxymoron
>
>
> On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
>
>>>The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
>>>will cause spurious ignorance of the remainder of the line, which is
>>>often very important. e.g.
>>>static INLINE int lock_need_resched(spinlock_t *lock)
>>>{
>>> ...
>
>
> On Sun, Sep 26, 2004 at 03:29:25AM +0200, Tonnerre wrote:
>
>>Mmm, shouldn't the comments be filtered *before* the definition is set
>>in place? Just wondering...
>
>
> I've already heard more about this than I ever cared to. I'll continue
> to stick to saner subsets of C and refuse to use things such as how the
> preprocessor committing incest with the compiler proper (no, I don't
> need it explained to me, it's trivial) allows crappy code to be written.
> Don't lecture me; there's nothing to explain and I don't want to hear it.
Don't hold back, tell us how you really feel ;-)
And I agree, those tricks shouldn't be used.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me