Re: kernel-2.2.1-undefined references.

Re: kernel-2.2.1-undefined references.

[H. Peter Anvin]

> Why is that a weakness? If the compiler's optimizer says "this code runs
> faster when not inlined" (I can think of a couple of reasons why it would
> even be right doing that...), I'm not qualified to contradict it.

No, you have it the wrong way around.  The human should be assumed
smarter than the compiler: if you say that this should be inlined, the
compiler better not contradict you.

	-hpa

Re: kernel-2.2.1-undefined references.

[Jeffrey A Law]

  In message < 199902081708.JAA13821@cesium.transmeta.com >you write:
  > > Why is that a weakness? If the compiler's optimizer says "this code runs
  > > faster when not inlined" (I can think of a couple of reasons why it would
  > > even be right doing that...), I'm not qualified to contradict it.
  > 
  > No, you have it the wrong way around.  The human should be assumed
  > smarter than the compiler: if you say that this should be inlined, the
  > compiler better not contradict you.
Let's not start this flamewar again.  Please.

If y'all want to argue about human vs compiler, take it elsewhere.



jeff

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 8 Feb 1999, Matthias Urlichs wrote:
> > Alan Cox:
> > > 
> > > At this point egcs really needs to invent a new "common inline" of some
> > > sort. There are kernel cases where you need to force inlining and where
> > > you don't want duplicated code all over the place caused by compiler
> > > weaknesses.
> > 
> Why is that a weakness? If the compiler's optimizer says "this code runs
> faster when not inlined" (I can think of a couple of reasons why it would
> even be right doing that...), I'm not qualified to contradict it.

Umm.. You're thinking the wrong way.

If the programmer tells the compiler that the function should be inlined,
the compiler had better comply with that.  At least until the compiler
guys are certain that the compiler is smarter than the programmer, at
which point I will concede just about anything.

For Gods sake, the compiler is a _tool_, and if I tell the compiler that I
want something inlined, it had damn well better do it.

When I tell the compiler to generate code to compute PI, I _expect_ to get
the numbers of PI, not "e". With me so far?

When I tell the compiler to do an "extern inline", I _expect_ to get an
inline function. I may have special requirements that the compiler doesn't
know about (no stack frame, whatever), and the compiler had better not
second-guess what the programmer really meant. For example, I may have
fixup code that gets invoced on exceptions, and that fixup code may care
about where the error happened.

It certainly doesn't have to be "extern inline", but I do believe that we
need to have to have _some_ way of forcing inlining. Saying "the compiler
knows best" is just stupid - the compiler does NOT know best, because it
hasn't got a frigging clue about what the programmer really wants.

		Linus

Re: kernel-2.2.1-undefined references.

[Chip Salzenberg]

According to Jeffrey A Law:
> If y'all want to argue about human vs compiler, take it elsewhere.

Doesn't it make sense, though, to be _able_ to force a given function
to be inlined, no matter what?
-- 
Chip Salzenberg      - a.k.a. -      <chip@perlsupport.com>
      "When do you work?"   "Whenever I'm not busy."

Re: kernel-2.2.1-undefined references.

[Joe Buck]

Linus writes:

> If the programmer tells the compiler that the function should be inlined,
> the compiler had better comply with that.  At least until the compiler
> guys are certain that the compiler is smarter than the programmer, at
> which point I will concede just about anything.

Developers need to understand the limitations of the tools they use.
Under certain circumstances, the compiler will not be able to comply
with a user request to inline a function.  This is just life.
However ...

> It certainly doesn't have to be "extern inline", but I do believe that we
> need to have to have _some_ way of forcing inlining.

I believe that you already have what you need, in the sense that there
is a flag that, when set, will warn you if the compiler did not inline
a function that was flagged "inline".

`-Winline'
     Warn if a function can not be inlined, and either it was declared
     as inline, or else the `-finline-functions' option was given.

If you rely on inlines being performed for correct function you can use
that flag.

Reasons I know of that may cause inlining to fail include recursion
(except for some cases of tail recursion) or too much forward referencing
(if an inline function calls another inline function, it works best if
they appear from innermost to outermost in the source).  Excessively
complex functions also may not be inlinable, though gcc can handle some
fairly large ones.  So if you get the warning above, you can attempt to
clean things up so that the compiler succeeds in inlining the function.

While the C++ and draft C9X standards docs say that inline is just a
hint, this is generally not true with gcc, which normally attempts to
comply with user requests for inlining, unless there is a reason why it
cannot (as in the above list).

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> Doesn't it make sense, though, to be _able_ to force a given function
> to be inlined, no matter what?

No.  There's recursion, dependence on other inline functions whose
definitions aren't available because of forward declaration (which you
could solve maybe my making the compiler store the whole input), use of API
features that require stack frames, etc.

If you replace "no matter what" with "except in certain well-defined
circumstances" it's doable.


		

Re: kernel-2.2.1-undefined references.

[H. Peter Anvin]

> 
> > Doesn't it make sense, though, to be _able_ to force a given function
> > to be inlined, no matter what?
> 
> No.  There's recursion, dependence on other inline functions whose
> definitions aren't available because of forward declaration (which you
> could solve maybe my making the compiler store the whole input), use of API
> features that require stack frames, etc.
> 
> If you replace "no matter what" with "except in certain well-defined
> circumstances" it's doable.
> 

Actually, you could simulate recursion (if you want to is another
issue), and forward declarations are just function calls (an inline,
proper, is defined at its point of declaration).

However, I think the right thing to do is to force an inline and if it
is impossible, document when it's impossible, and give an error.

	-hpa

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> Actually, you could simulate recursion (if you want to is another
> issue),

You don't want to (except that tail recursion can be handled).

> and forward declarations are just function calls (an inline,
> proper, is defined at its point of declaration).

Not in C++; you can (and sometimes must) declare that an inline function
will occur later, and more forward declaration is possible.

> However, I think the right thing to do is to force an inline and if it
> is impossible, document when it's impossible, and give an error.

Currently, you get a warning if you specify -Winline (and inlining is
enabled).  I don't see any reason to change it to an error (there's
a separate flag that will treat any warning as an error, so you could
use that).

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Joe Buck wrote:
> 
> `-Winline'
>      Warn if a function can not be inlined, and either it was declared
>      as inline, or else the `-finline-functions' option was given.
> 
> If you rely on inlines being performed for correct function you can use
> that flag.

What?

Do you imply that the flag will also change code generation?

I assume not. You're just saying that "yes, the compiler will screw you,
but now it will laugh derisively when it does so".

That doesn't make me any happier, and if you don't see why, then I can't
help you.

		Linus

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Joe Buck wrote:
> 
> > Doesn't it make sense, though, to be _able_ to force a given function
> > to be inlined, no matter what?
> 
> No.  There's recursion, dependence on other inline functions whose
> definitions aren't available because of forward declaration (which you
> could solve maybe my making the compiler store the whole input), use of API
> features that require stack frames, etc.
> 
> If you replace "no matter what" with "except in certain well-defined
> circumstances" it's doable.

Sure. Anybody who marks a recursive function inline should probably just
get an outright error, regardless of what flags were passed in (but I
imagine that that is disallowed by the ANSI people, so just make it a
warning). 

Same goes for using inline functions before declaring them - there's no
point in even asking the compiler to do global parsing (a compiler may
offer it if it wants to, but requireing it is fairly obnoxious). 

I'm not trying to be unreasonable. I'm just saying that if there is a
function that is marked inline that can be inlined, it _should_ be
inlined, because the compiler _never_ knows better than the programmer.

		Linus

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> On Mon, 8 Feb 1999, Joe Buck wrote:
> > 
> > `-Winline'
> >      Warn if a function can not be inlined, and either it was declared
> >      as inline, or else the `-finline-functions' option was given.
> > 
> > If you rely on inlines being performed for correct function you can use
> > that flag.
> 
> What?
> 
> Do you imply that the flag will also change code generation?
> 
> I assume not. You're just saying that "yes, the compiler will screw you,
> but now it will laugh derisively when it does so".

No, the compiler will tell you if it has failed to inline the function
(which almost never will happen, but if it does, will no longer happen
silently).

You can then fix the problem that was preventing the compiler from
inlining the function.  If you see no messages you can safely assume
that all of your functions are inlined.

> That doesn't make me any happier, and if you don't see why, then I can't
> help you.

Sorry, if you picture the compiler "screwing you" and then "laughing
derisively", perhaps the recent stress of getting the kernel release out
was a bit much and some time off will help. :-)  The compiler people
aren't plotting against you, it's just that functions can't always be
inlined.

I don't think you have a reason to be unhappy, unless you can point out
a specific function that is not being inlined.

Re: kernel-2.2.1-undefined references.

[Per Bothner]

> I'm not trying to be unreasonable. I'm just saying that if there is a
> function that is marked inline that can be inlined, it _should_ be
> inlined, because the compiler _never_ knows better than the programmer.

Er, the compiler often knows better than the programmer.  That is why
we use compilers - to free us from low-level and architecture-dependent
decisions.

Note you have a rather atypical perspective.  You know the hardware
in depth, and you know which instruction sequences will be faster.
You probably know (or at least can make an informed guess) if inline
will help or hinder the code.  You also sometimes need precise control
over low-level code.

We cannot design a compiler for the Linux Torvalds' of the world.
We have to do what is best for *most* programmers, while still
providing the needed tools for the experts.

I really don't understand your objection to -Winline, optionally
combined with -Werror.  It seems to give you pretty close to
what you need:  A good-faith effort from the compiler to inline
when you ask it to, plus a warning or error when it cannot.
What more can the compiler possibly do?

Are you saying the compiler should also obey "register" directives,
because the programmer knows better?

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: kernel-2.2.1-undefined references.

[Michael Gschwind]

> Same goes for using inline functions before declaring them - there's no
> point in even asking the compiler to do global parsing (a compiler may
> offer it if it wants to, but requireing it is fairly obnoxious). 

That type of reasoning is not very standards-minded, but more like
special casing things that current compilers would generally do?

And besides, note that other compile hints, such as the "register"
attribute doesn't have to be adhered to, either.

It is safest when programming languages specify the semantics of the
program, and not bind some implementation meaning in... If for some
reason the compiler cannot inline it, then I think it is reasonable to
generate non-inlined code.  

> I'm not trying to be unreasonable. I'm just saying that if there is a
> function that is marked inline that can be inlined, it _should_ be
> inlined, because the compiler _never_ knows better than the programmer.

And compilers are dumb, so what should the compiler do with a register
attribute, when no registers are left?  Abort the compile run or
settle for the less perfect choice by allocating a stack frame slot?

I understand what your point is, i.e., I don't think the compiler
should CHOOSE to ignore the programer, but there can be a number
of reasons why the compiler may have no other choice. I think that is
what Joe was trying to tell you.  (And the reasons behind the compiler
not being to inline some functions may include deficiencies in the
compiler, as well as cost/benefit tradeoffs relating to memory
availability.   I must say I hate the latter type of limitations and
just wish all tools had a switch to use as much memory as deemed
necessary...)


m.

-- 
Michael K. Gschwind
IBM T.J. Watson Research Center     phone (external): (914) 945-3162
PO Box 218                          phone (internal): T/L 862-3162
Yorktown Heights, NY 10598          e-mail: mikeg@watson.ibm.com

Re: kernel-2.2.1-undefined references.

[H. Peter Anvin]

> I really don't understand your objection to -Winline, optionally
> combined with -Werror.  It seems to give you pretty close to
> what you need:  A good-faith effort from the compiler to inline
> when you ask it to, plus a warning or error when it cannot.
> What more can the compiler possibly do?
> 
> Are you saying the compiler should also obey "register" directives,
> because the programmer knows better?

Yes.

	-hpa

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 09:38 AM 2/8/99 -0800, "Linus Torvalds" wrote:

[deletia]

Holy sh!t ... er... Is that really Linus Torvalds himself?

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Matthias Urlichs]

Hi,

Linus Torvalds:
> 
> If the programmer tells the compiler that the function should be inlined,
> the compiler had better comply with that.  At least until the compiler
> guys are certain that the compiler is smarter than the programmer, at
> which point I will concede just about anything.
> 
The problem wit inline vs. register is that it doesn't hurt one bit whether
anybody listens to the difference of "register int" vs. "int" -- the code
still works; the assembler output looks different, but so what? The
difference between ignoring the inline in "extern inline" or not is that
the kernel doesn't link (or kernel modules don't insert) which is a wholly
different kettle of fish.

> For Gods sake, the compiler is a _tool_, and if I tell the compiler that I
> want something inlined, it had damn well better do it.
> 
It's too bad that ISO and/or EGCS now have a definition for "extern inline"
which clashes with (until now) accepted usage in the kernel.

IMHO it's not very productive to complain to anybody about this; we need to
find a way to fix the problem. I'd say that reverting ECGS's behavior isn't
going to be acceptable for a variety of reasons.

A -fforce-inline flag (which seems to be implementable rather cheaply) has
the disadvantage that it's not a very finegrained solution. Therefore I'd
personally prefer __attribute__((force_inline)) or some such.

Alternately, we could autogenerate a library with "real" implementations
of all the "extern inline" functions found in header files (to do this is
rather simple) and replace the one-shot this-is-a-separate-function-
-'cause-it-looks-nicer "extern inline"s in the kernel's .c files with
"static inline".


I'd like to arrive at a rough consensus first, though, before anybody
starts to hack away on either the kernel or EGCS -- wasted effort leads to
frustrated hackers, who then give up and decide they'd rather spend their
time on the closed-source stuff which their employer thinks they're paying
them for in the first place...  :-/

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
The control of the production of wealth is the control of human life itself.
               --Hilaire Belloc

Re: kernel-2.2.1-undefined references.

[Nick Ing-Simmons]

H . Peter Anvin <hpa@transmeta.com> writes:

>Actually, you could simulate recursion (if you want to is another
>issue), 

How do you inline this : 

inline int factorial(int n)
{
 if (n == 0)
  return 1;
 return factorial(n-1)*n;
}
-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> 
> H . Peter Anvin <hpa@transmeta.com> writes:
> 
> >Actually, you could simulate recursion (if you want to is another
> >issue), 
> 
> How do you inline this : 
> 
> inline int factorial(int n)
> {
>  if (n == 0)
>   return 1;
>  return factorial(n-1)*n;
> }

That's not too hard, it can be done completely mechanically.  (Other
forms of recursion can't be transformed in the way I'm about to describe,
but this one can).

First you have to figure out how to make it tail-recursive.  It's not
quite tail-recursive, since you have "return factorial(n-1)*n" rather than
"return factorial(n-1)".  You can make a function factorial2(int n, int m)
that returns m*n.  So now you can write

inline int factorial2(int n, int m)
{
	if (n == 0)
		return 1*m;
	else
		return factorial2(n-1, n*m);
}

This kind of transformation isn't hard to do mechanically.  We now have a
tail-recursive function.  We can eliminate the recursion now by making a
loop:

inline int factorial2(int n, int m)
{
	while (1) {
		if (n == 0)	
			return m;
		else
			m = n * m;
			n = n - 1;
		}
	}
}

Finally, the original call is to factorial, not factorial2, so:

inline int factorial(int n)
{
	int m = 1;
	while (1) {
		if (n == 0)	
			return m;
		else
			m = n * m;
			n = n - 1;
		}
	}
}

We can pretty it up a bit:

inline int factorial(int n)
{
	int m = 1;
	while (n != 0) {
		m = n * m;
		n = n - 1;
	}
	return m;
}

Re: kernel-2.2.1-undefined references.

[craig]

>How do you inline this : 
>
>inline int factorial(int n)
>{
> if (n == 0)
>  return 1;
> return factorial(n-1)*n;
>}

Could we not teach Computer Science .101 here?  I mean, it'd be fun
to type in an answer, but....

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Alan Cox]

> > Why is that a weakness? If the compiler's optimizer says "this code runs
> > faster when not inlined" (I can think of a couple of reasons why it would
> > even be right doing that...), I'm not qualified to contradict it.
> 
> No, you have it the wrong way around.  The human should be assumed
> smarter than the compiler: if you say that this should be inlined, the
> compiler better not contradict you.

Ive been away so this is a bit of a late final reply

I think both sides are right.

o	The compiler should by default do what it feels is right
	That includes inlining and uninlining code

o	The compiler has to have a way you can tell it "or else".

	extern __inline_or_i_beat_you_to_death__ 

	or similar

Re: kernel-2.2.1-undefined references.

[Chip Salzenberg]

According to Jeffrey A Law:
> If y'all want to argue about human vs compiler, take it elsewhere.

Doesn't it make sense, though, to be _able_ to force a given function
to be inlined, no matter what?
-- 
Chip Salzenberg      - a.k.a. -      <chip@perlsupport.com>
      "When do you work?"   "Whenever I'm not busy."

Re: kernel-2.2.1-undefined references.

[H. Peter Anvin]

> 
> > Doesn't it make sense, though, to be _able_ to force a given function
> > to be inlined, no matter what?
> 
> No.  There's recursion, dependence on other inline functions whose
> definitions aren't available because of forward declaration (which you
> could solve maybe my making the compiler store the whole input), use of API
> features that require stack frames, etc.
> 
> If you replace "no matter what" with "except in certain well-defined
> circumstances" it's doable.
> 

Actually, you could simulate recursion (if you want to is another
issue), and forward declarations are just function calls (an inline,
proper, is defined at its point of declaration).

However, I think the right thing to do is to force an inline and if it
is impossible, document when it's impossible, and give an error.

	-hpa

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> Actually, you could simulate recursion (if you want to is another
> issue),

You don't want to (except that tail recursion can be handled).

> and forward declarations are just function calls (an inline,
> proper, is defined at its point of declaration).

Not in C++; you can (and sometimes must) declare that an inline function
will occur later, and more forward declaration is possible.

> However, I think the right thing to do is to force an inline and if it
> is impossible, document when it's impossible, and give an error.

Currently, you get a warning if you specify -Winline (and inlining is
enabled).  I don't see any reason to change it to an error (there's
a separate flag that will treat any warning as an error, so you could
use that).

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> Doesn't it make sense, though, to be _able_ to force a given function
> to be inlined, no matter what?

No.  There's recursion, dependence on other inline functions whose
definitions aren't available because of forward declaration (which you
could solve maybe my making the compiler store the whole input), use of API
features that require stack frames, etc.

If you replace "no matter what" with "except in certain well-defined
circumstances" it's doable.


		

Re: kernel-2.2.1-undefined references.

[Joe Buck]

Linus writes:

> If the programmer tells the compiler that the function should be inlined,
> the compiler had better comply with that.  At least until the compiler
> guys are certain that the compiler is smarter than the programmer, at
> which point I will concede just about anything.

Developers need to understand the limitations of the tools they use.
Under certain circumstances, the compiler will not be able to comply
with a user request to inline a function.  This is just life.
However ...

> It certainly doesn't have to be "extern inline", but I do believe that we
> need to have to have _some_ way of forcing inlining.

I believe that you already have what you need, in the sense that there
is a flag that, when set, will warn you if the compiler did not inline
a function that was flagged "inline".

`-Winline'
     Warn if a function can not be inlined, and either it was declared
     as inline, or else the `-finline-functions' option was given.

If you rely on inlines being performed for correct function you can use
that flag.

Reasons I know of that may cause inlining to fail include recursion
(except for some cases of tail recursion) or too much forward referencing
(if an inline function calls another inline function, it works best if
they appear from innermost to outermost in the source).  Excessively
complex functions also may not be inlinable, though gcc can handle some
fairly large ones.  So if you get the warning above, you can attempt to
clean things up so that the compiler succeeds in inlining the function.

While the C++ and draft C9X standards docs say that inline is just a
hint, this is generally not true with gcc, which normally attempts to
comply with user requests for inlining, unless there is a reason why it
cannot (as in the above list).

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 09:38 AM 2/8/99 -0800, "Linus Torvalds" wrote:

[deletia]

Holy sh!t ... er... Is that really Linus Torvalds himself?

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[craig]

>How do you inline this : 
>
>inline int factorial(int n)
>{
> if (n == 0)
>  return 1;
> return factorial(n-1)*n;
>}

Could we not teach Computer Science .101 here?  I mean, it'd be fun
to type in an answer, but....

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Joe Buck wrote:
> 
> `-Winline'
>      Warn if a function can not be inlined, and either it was declared
>      as inline, or else the `-finline-functions' option was given.
> 
> If you rely on inlines being performed for correct function you can use
> that flag.

What?

Do you imply that the flag will also change code generation?

I assume not. You're just saying that "yes, the compiler will screw you,
but now it will laugh derisively when it does so".

That doesn't make me any happier, and if you don't see why, then I can't
help you.

		Linus

Re: kernel-2.2.1-undefined references.

[Jeffrey A Law]

  In message < 199902081708.JAA13821@cesium.transmeta.com >you write:
  > > Why is that a weakness? If the compiler's optimizer says "this code runs
  > > faster when not inlined" (I can think of a couple of reasons why it would
  > > even be right doing that...), I'm not qualified to contradict it.
  > 
  > No, you have it the wrong way around.  The human should be assumed
  > smarter than the compiler: if you say that this should be inlined, the
  > compiler better not contradict you.
Let's not start this flamewar again.  Please.

If y'all want to argue about human vs compiler, take it elsewhere.



jeff

Re: kernel-2.2.1-undefined references.

[H. Peter Anvin]

> I really don't understand your objection to -Winline, optionally
> combined with -Werror.  It seems to give you pretty close to
> what you need:  A good-faith effort from the compiler to inline
> when you ask it to, plus a warning or error when it cannot.
> What more can the compiler possibly do?
> 
> Are you saying the compiler should also obey "register" directives,
> because the programmer knows better?

Yes.

	-hpa

Re: kernel-2.2.1-undefined references.

[Alan Cox]

> > Why is that a weakness? If the compiler's optimizer says "this code runs
> > faster when not inlined" (I can think of a couple of reasons why it would
> > even be right doing that...), I'm not qualified to contradict it.
> 
> No, you have it the wrong way around.  The human should be assumed
> smarter than the compiler: if you say that this should be inlined, the
> compiler better not contradict you.

Ive been away so this is a bit of a late final reply

I think both sides are right.

o	The compiler should by default do what it feels is right
	That includes inlining and uninlining code

o	The compiler has to have a way you can tell it "or else".

	extern __inline_or_i_beat_you_to_death__ 

	or similar

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Joe Buck wrote:
> 
> > Doesn't it make sense, though, to be _able_ to force a given function
> > to be inlined, no matter what?
> 
> No.  There's recursion, dependence on other inline functions whose
> definitions aren't available because of forward declaration (which you
> could solve maybe my making the compiler store the whole input), use of API
> features that require stack frames, etc.
> 
> If you replace "no matter what" with "except in certain well-defined
> circumstances" it's doable.

Sure. Anybody who marks a recursive function inline should probably just
get an outright error, regardless of what flags were passed in (but I
imagine that that is disallowed by the ANSI people, so just make it a
warning). 

Same goes for using inline functions before declaring them - there's no
point in even asking the compiler to do global parsing (a compiler may
offer it if it wants to, but requireing it is fairly obnoxious). 

I'm not trying to be unreasonable. I'm just saying that if there is a
function that is marked inline that can be inlined, it _should_ be
inlined, because the compiler _never_ knows better than the programmer.

		Linus

Re: kernel-2.2.1-undefined references.

[Per Bothner]

> I'm not trying to be unreasonable. I'm just saying that if there is a
> function that is marked inline that can be inlined, it _should_ be
> inlined, because the compiler _never_ knows better than the programmer.

Er, the compiler often knows better than the programmer.  That is why
we use compilers - to free us from low-level and architecture-dependent
decisions.

Note you have a rather atypical perspective.  You know the hardware
in depth, and you know which instruction sequences will be faster.
You probably know (or at least can make an informed guess) if inline
will help or hinder the code.  You also sometimes need precise control
over low-level code.

We cannot design a compiler for the Linux Torvalds' of the world.
We have to do what is best for *most* programmers, while still
providing the needed tools for the experts.

I really don't understand your objection to -Winline, optionally
combined with -Werror.  It seems to give you pretty close to
what you need:  A good-faith effort from the compiler to inline
when you ask it to, plus a warning or error when it cannot.
What more can the compiler possibly do?

Are you saying the compiler should also obey "register" directives,
because the programmer knows better?

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 8 Feb 1999, Matthias Urlichs wrote:
> > Alan Cox:
> > > 
> > > At this point egcs really needs to invent a new "common inline" of some
> > > sort. There are kernel cases where you need to force inlining and where
> > > you don't want duplicated code all over the place caused by compiler
> > > weaknesses.
> > 
> Why is that a weakness? If the compiler's optimizer says "this code runs
> faster when not inlined" (I can think of a couple of reasons why it would
> even be right doing that...), I'm not qualified to contradict it.

Umm.. You're thinking the wrong way.

If the programmer tells the compiler that the function should be inlined,
the compiler had better comply with that.  At least until the compiler
guys are certain that the compiler is smarter than the programmer, at
which point I will concede just about anything.

For Gods sake, the compiler is a _tool_, and if I tell the compiler that I
want something inlined, it had damn well better do it.

When I tell the compiler to generate code to compute PI, I _expect_ to get
the numbers of PI, not "e". With me so far?

When I tell the compiler to do an "extern inline", I _expect_ to get an
inline function. I may have special requirements that the compiler doesn't
know about (no stack frame, whatever), and the compiler had better not
second-guess what the programmer really meant. For example, I may have
fixup code that gets invoced on exceptions, and that fixup code may care
about where the error happened.

It certainly doesn't have to be "extern inline", but I do believe that we
need to have to have _some_ way of forcing inlining. Saying "the compiler
knows best" is just stupid - the compiler does NOT know best, because it
hasn't got a frigging clue about what the programmer really wants.

		Linus

Re: kernel-2.2.1-undefined references.

[H. Peter Anvin]

> Why is that a weakness? If the compiler's optimizer says "this code runs
> faster when not inlined" (I can think of a couple of reasons why it would
> even be right doing that...), I'm not qualified to contradict it.

No, you have it the wrong way around.  The human should be assumed
smarter than the compiler: if you say that this should be inlined, the
compiler better not contradict you.

	-hpa

Re: kernel-2.2.1-undefined references.

[Michael Gschwind]

> Same goes for using inline functions before declaring them - there's no
> point in even asking the compiler to do global parsing (a compiler may
> offer it if it wants to, but requireing it is fairly obnoxious). 

That type of reasoning is not very standards-minded, but more like
special casing things that current compilers would generally do?

And besides, note that other compile hints, such as the "register"
attribute doesn't have to be adhered to, either.

It is safest when programming languages specify the semantics of the
program, and not bind some implementation meaning in... If for some
reason the compiler cannot inline it, then I think it is reasonable to
generate non-inlined code.  

> I'm not trying to be unreasonable. I'm just saying that if there is a
> function that is marked inline that can be inlined, it _should_ be
> inlined, because the compiler _never_ knows better than the programmer.

And compilers are dumb, so what should the compiler do with a register
attribute, when no registers are left?  Abort the compile run or
settle for the less perfect choice by allocating a stack frame slot?

I understand what your point is, i.e., I don't think the compiler
should CHOOSE to ignore the programer, but there can be a number
of reasons why the compiler may have no other choice. I think that is
what Joe was trying to tell you.  (And the reasons behind the compiler
not being to inline some functions may include deficiencies in the
compiler, as well as cost/benefit tradeoffs relating to memory
availability.   I must say I hate the latter type of limitations and
just wish all tools had a switch to use as much memory as deemed
necessary...)


m.

-- 
Michael K. Gschwind
IBM T.J. Watson Research Center     phone (external): (914) 945-3162
PO Box 218                          phone (internal): T/L 862-3162
Yorktown Heights, NY 10598          e-mail: mikeg@watson.ibm.com

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> On Mon, 8 Feb 1999, Joe Buck wrote:
> > 
> > `-Winline'
> >      Warn if a function can not be inlined, and either it was declared
> >      as inline, or else the `-finline-functions' option was given.
> > 
> > If you rely on inlines being performed for correct function you can use
> > that flag.
> 
> What?
> 
> Do you imply that the flag will also change code generation?
> 
> I assume not. You're just saying that "yes, the compiler will screw you,
> but now it will laugh derisively when it does so".

No, the compiler will tell you if it has failed to inline the function
(which almost never will happen, but if it does, will no longer happen
silently).

You can then fix the problem that was preventing the compiler from
inlining the function.  If you see no messages you can safely assume
that all of your functions are inlined.

> That doesn't make me any happier, and if you don't see why, then I can't
> help you.

Sorry, if you picture the compiler "screwing you" and then "laughing
derisively", perhaps the recent stress of getting the kernel release out
was a bit much and some time off will help. :-)  The compiler people
aren't plotting against you, it's just that functions can't always be
inlined.

I don't think you have a reason to be unhappy, unless you can point out
a specific function that is not being inlined.

Re: kernel-2.2.1-undefined references.

[Matthias Urlichs]

Hi,

Linus Torvalds:
> 
> If the programmer tells the compiler that the function should be inlined,
> the compiler had better comply with that.  At least until the compiler
> guys are certain that the compiler is smarter than the programmer, at
> which point I will concede just about anything.
> 
The problem wit inline vs. register is that it doesn't hurt one bit whether
anybody listens to the difference of "register int" vs. "int" -- the code
still works; the assembler output looks different, but so what? The
difference between ignoring the inline in "extern inline" or not is that
the kernel doesn't link (or kernel modules don't insert) which is a wholly
different kettle of fish.

> For Gods sake, the compiler is a _tool_, and if I tell the compiler that I
> want something inlined, it had damn well better do it.
> 
It's too bad that ISO and/or EGCS now have a definition for "extern inline"
which clashes with (until now) accepted usage in the kernel.

IMHO it's not very productive to complain to anybody about this; we need to
find a way to fix the problem. I'd say that reverting ECGS's behavior isn't
going to be acceptable for a variety of reasons.

A -fforce-inline flag (which seems to be implementable rather cheaply) has
the disadvantage that it's not a very finegrained solution. Therefore I'd
personally prefer __attribute__((force_inline)) or some such.

Alternately, we could autogenerate a library with "real" implementations
of all the "extern inline" functions found in header files (to do this is
rather simple) and replace the one-shot this-is-a-separate-function-
-'cause-it-looks-nicer "extern inline"s in the kernel's .c files with
"static inline".


I'd like to arrive at a rough consensus first, though, before anybody
starts to hack away on either the kernel or EGCS -- wasted effort leads to
frustrated hackers, who then give up and decide they'd rather spend their
time on the closed-source stuff which their employer thinks they're paying
them for in the first place...  :-/

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
The control of the production of wealth is the control of human life itself.
               --Hilaire Belloc

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 04:25 PM 2/14/99 PST, you wrote:

>You are incorrect, I'm afraid.  What Fortran construct corresponds
>to "volatile", which is in essence a model for a memory-mapped device
>register?

Or a variable that may be modified asynchronously by software, e.g. a
hardware interrupt, a signal handler, multiple threads in a multithreaded
program...

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[craig]

>> Be aware that __builtin_return_address probably will stop working
>> someday in gcc.  Read my latest tirade to get an idea of why that is.
>
>Craig, gcc is the GNU project's compiler.  That means that one of its
>important roles is to be able to compile kernels (Linux or the Hurd).
>Since you're the Fortran guy, you are somewhat insulated from these
>issues (Fortran just doesn't make provisions for writing "close to the
>machine" code).

Actually, I'm not talking as the "Fortran guy".  I'm talking as someone
who understands operating systems development and computer-architecture
issues better than he understands Fortran compiler development.

And, note, C doesn't really make provisions for writing "close to the
machine" code any better than Fortran.  It provides a *model* that
more closely parallels many of today's most popular architectures,
making it more "obvious" to today's programmers that a straightforward
translation is possible, but *nothing* in the C standard, aside
from stuff like `volatile' (assuming that's even in the standard),
says anything about the mapping to the underlying machine.  But the
"as if" rule means you can't just *assume* the machine will behave
a certain way when running C code.

(I've worked on operating systems written in Fortran, assembler, and
PL/1, but no C, by the way.)

I've written on this range of topics, especially involving C, C++,
Fortran, and operators, on USENET many times in the past, so I don't
think it behooves anyone to go into more details.  I'll just disagree
with the assertion and leave it at that, noting that the way Fortran
offers similar *effects* as almost all of C's facilities does, usually,
require somewhat more typing.  :)

>The result is that gcc is going to have to continue to support certain
>extensions for the indefinite future (though kernel developers should
>not assume that "it worked in version x.y.z" is a commitment for the
>future, we will need to supply some mechanisms in some cases.

Oh, I agree.  I'm not saying that feature *will* stop working, just
that, at some point in the future, when gcc is *expected* to support
high-performance platforms like massively parallel machines, it will
either have to stop returning anything other than 0 from that
function in many cases, or the mere use of that function will
mandate a substantial drop in performance of the compiled code,
if my guesses about future directions of computing are correct (and
they're hardly controversial).

If that substantial drop happens, the users who notice it will
complain saying "it stopped working", is my prediction.

>It may actually be easier to support features like this if they are
>specified at a higher level of abstraction.  That is, understand why Linus
>is using some trick to do something, and then recommend alternative ways
>to do them that are actually supportable.  e.g. if the real job is to get
>a stack trace, maybe there could be some facility to provide for that
>directly, possibly borrowing some code from gdb.

Exactly.  Doing that is pretty hard, but I think it's better to try
and do it up front, offer the most SWYM-like ways for people like
Linus to express themselves, and support *that* as well as possible.

(After all, what the heck *is* a "stack trace", precisely defined,
and exactly how does "getting" it help Linux developers?  As soon
as you start answering by talking about frame and stack pointers,
you've headed off the SWYM reservation and are assuming a particular
machine model for gcc to permanently cater to, at the expense of
more powerful machines that don't fit that model.)

Instead, for the time being, practical concerns dictate (or have
dictated) offering fairly straightforward hooks of the DWIS variety,
which tend to mandate some kind of common machine model which,
though ill-defined, matches most or all of today's targets, but
which won't necessarily match some of tomorrow's.

If and when that happens, the old DWIS constructs must, for the
new, different models, either be dropped (rendered innocuous,
whatever), or implemented such that their mere presence shuts
down lots of important optimizations.

>Despite Linus's tendency to be insulting, he is one our most important
>"customers" (or, more accurately, the people who depend on the Linux
>kernel working are).  We need to have sufficient facilities so that C plus
>inline assembly can do the whole job.

That's a highly worthy goal.  Do you think gcc's important customers
also include all those people who just write straightforward,
standard-conforming code and want it to go as fast as possible on
the most powerful machines available at the time?  I do, and these
customers basically rely on the SWYM aspects of code generation for
gcc's family of languages.

Do you think gcc can evolve to handle both those kinds of customers
and the Linux kind, which expects all the existing DWIS-like hooks
(which assume a certain static machine model) to continue working
forever, without becoming unmaintainable?  I don't.

In any case, do you think it'll be *easier* or *harder* to maintain
gcc if products like Linux are encouraged to slowly dispense with
dependencies on gcc's current DWIS-like extensions, so both Linux
and gcc are less dependent on assuming a certain static machine
model that has informed the development and use of so many of gcc's
extensions?

I think it'd be *easier*, and the sooner it's done, the better.

Finally, I'll ask a different version of the same question I posed
earlier:

Will it ever be acceptable for any version of gcc to generate substantially
different code for an application due to the addition of a single
reference to a function like `__builtin_return_address', making for
possibly *large* differences in performance between the two versions,
and perhaps in the reproducibility of bugs in the code, due to
all sorts of code and data being moved around?

        tq vm, (burley)

P.S. It's unclear to me whether C will survive long enough to make
any of the issues I raise above matter.  That is, if we can predict
its "death", meaning the point at which improving it further becomes
a non-issue for the industry, then perhaps we can also predict the
final sorts of uses to which it'll be put.  There's reasons to believe
those uses will be much more DWIS-like than SWYM-like, and others
reasons to believe the other way.  I lean towards the former, which
is why I don't get excited about the SWYM features C9X or whoever
are adding to the language: I think they'll hasten, not delay, the
death of C, because they'll just keep making a hard language harder
to use, which is death for SWYM purposes.

Anyway, once the industry decides C will finally become a DWIS-like
language for sure (let's say), then its "body of development" will
become like a corpse -- anyone who wants to pick at it, by adding
the DWIS features they need at the moment, will feel comfortable
doing so.  They'll know they aren't coding for the distant future.
gcc can then support whatever DWIS extensions it wants at that point.

But the same issues persist for other gcc languages, though I think
C++ will die before C does, because they include Fortran, Java,
Ada, and so on.

So the gcc *back end* will have to support *all* of these combinations
of SWYM and DWIS extensions, and still meet all the expectations placed
on it to generate great code for every machine imaginable.

I think that might become extremely hard to manage someday, and the
symptoms will probably be a serious development split when it comes
to supporting some new, weird, high-performance machine, for which
many of the DWIS extensions make little or no sense.

But I could be wrong, and wouldn't mind being proven so: if gcc could
literally become the world's catch-all code generator, beautifully
optimizing clean code targeting every machine, including the bizarre
ones, while also accommodating the needs of people who want to micro-
manage its code generation, that'd be *great*.

Re: kernel-2.2.1-undefined references.

[Marc Espie]

In article < Pine.LNX.3.95.990208183457.433I-100000@penguin.transmeta.com > you write:

>In particular, "extern inline" has basically been documented to be a macro
>(some Clintonesque arguments to the contrary notwithstanding), and does
>not make sense to not inline - the documentation even says so. If I have
>to add an "extern" to force the inline, that's fine.

I'm sorry but this is bullshit. Read the fucking manual. I even took the time
to research gcc 2.7.2' extend.texi. Is that old enough for you ?
I have included the whole node of the documentation *here* so that you can't
accuse me of trying to finnagle my way out of a tight place...

------------------------
| @section An Inline Function is As Fast As a Macro
| @cindex inline functions
| @cindex integrating function code
| @cindex open coding
| @cindex macros, inline alternative
| 
| By declaring a function @code{inline}, you can direct GNU CC to
| integrate that function's code into the code for its callers.  This
| makes execution faster by eliminating the function-call overhead; in
| addition, if any of the actual argument values are constant, their known
| values may permit simplifications at compile time so that not all of the
| inline function's code needs to be included.  The effect on code size is
| less predictable; object code may be larger or smaller with function
| inlining, depending on the particular case.  Inlining of functions is an
| optimization and it really ``works'' only in optimizing compilation.  If
| you don't use @samp{-O}, no function is really inline.

First point, inlining is an optimization. As far as I know, optimizations
are fine-tuning, that should be termed as not changing semantics.

| To declare a function inline, use the @code{inline} keyword in its
| declaration, like this:
| 
| @example
| inline int
| inc (int *a)
| @{
|   (*a)++;
| @}
| @end example
| 
| (If you are writing a header file to be included in ANSI C programs, write
| @code{__inline__} instead of @code{inline}.  @xref{Alternate Keywords}.)

| You can also make all ``simple enough'' functions inline with the option
| @samp{-finline-functions}.  Note that certain usages in a function
| definition can make it unsuitable for inline substitution.

*WHAT* is not clear in the preceding paragraph ?  Stuff covered
by `certain usages in a function definition' is obviously very vague,
but the intent is not: inlining is an *optimization*. The compiler had better
do its damned best to implement it, but it has *no obligation* to inline
functions.

| Note that in C and Objective C, unlike C++, the @code{inline} keyword
| does not affect the linkage of the function.

| @cindex automatic @code{inline} for C++ member fns
| @cindex @code{inline} automatic for C++ member fns
| @cindex member fns, automatically @code{inline}
| @cindex C++ member fns, automatically @code{inline}
| GNU CC automatically inlines member functions defined within the class
| body of C++ programs even if they are not explicitly declared
| @code{inline}.  (You can override this with @samp{-fno-default-inline};
| @pxref{C++ Dialect Options,,Options Controlling C++ Dialect}.)

| @cindex inline functions, omission of
| When a function is both inline and @code{static}, if all calls to the
| function are integrated into the caller, and the function's address is
| never used, then the function's own assembler code is never referenced.
| In this case, GNU CC does not actually output assembler code for the
| function, unless you specify the option @samp{-fkeep-inline-functions}.
| Some calls cannot be integrated for various reasons (in particular,
| calls that precede the function's definition cannot be integrated, and
| neither can recursive calls within the definition).  If there is a
| nonintegrated call, then the function is compiled to assembler code as
| usual.  The function must also be compiled as usual if the program
| refers to its address, because that can't be inlined.
| 
| @cindex non-static inline function
| When an inline function is not @code{static}, then the compiler must assume
| that there may be calls from other source files; since a global symbol can
| be defined only once in any program, the function must not be defined in
| the other source files, so the calls therein cannot be integrated.
| Therefore, a non-@code{static} inline function is always compiled on its
| own in the usual fashion.
| 
| If you specify both @code{inline} and @code{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.

| This combination of @code{inline} and @code{extern} has almost the
                                                          ^^^^^^
| effect of a macro.  The way to use it is to put a function definition in
| a header file with these keywords, and put another copy of the
| definition (lacking @code{inline} and @code{extern}) in a library file.
| The definition in the header file will cause most calls to the function
                                               ^^^^
| to be inlined.  If any uses of the function remain, they will refer to
| the single copy in the library.

I fail to see what's unclear about the preceding paragraph. The intent
is clear, code design is clear (why would you want to provide a library
definition for extern inline, except for the fact that not all calls are
guaranteed to be inlined).

| GNU C does not inline any functions when not optimizing.  It is not
| clear whether it is better to inline or not, in this case, but we found
| that a correct implementation when not optimizing was difficult.  So we
| did the easy thing, and turned it off.
| 

>Removing features without giving a reasonable way of doing the thing that
>gcc has successfully been doing for 8 years is not reasonable.

You can make a case for *changing* the documentation, you can say that 
egcs current is breaking your code, but the feature you're asking is
basically undocumented.  Heck, this old piece of evidence, which has not
changed thru gcc 2.8.1, and now egcs, contradicts your ranting.

>Codifying the fact that if you really _rely_ on inlines, do so with an
>"extern inline" is ok would be very reasonable. Maybe you could even say
>that "extern inline" is honoured even when not optimizing.

Documentation *explicitly* says otherwise. Documentation *explicitly* tells
you that you should not _rely_ on extern inline exclusively.

>> I prefer to follow the standard where it says that inline is a hint,
>> and only a hint.
>
>You also seem to prefer breaking documented behaviour.

Undocumented.

Now, don't get me wrong. I perfectly agree with you that it would be better
if egcs were able to inline the same functions (and more) than gcc used
to be able to. This is your way of asking that gets on my nerves.

Breaking compilers gratuitously is probably something the egcs folks are
not doing. They're trying hard to do a good job, and there are compromises
sometimes that need to be done.   The current documentation shows some
leeway for the compiler implementor. Changing slightly actually inlined 
functions does not contradict the documentation. Hell, it should not even
break code (apart from performance), or else, blech. There are some parts
of the Linux kernel I *don't* want to touch.

>You also seem to want to ignore the knowledgeable user that knows, for
>example, that yes, this is a frigging big inline, but it's only used in
>one place, and it's inline in order to make the code more readable, but I
>really want to have the compiler inline it for me to make the code faster. 

>Why not just say that for "extern inline" there are NO artifical limits,
>because the damn documentation _tells_ you that "extern inline" is a gcc
>extension to the language that creates a macro-like function. 

>Instead of breaking stuff that used to work. 

Well, telling it another way, you got bitten by non-portable code...

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> And, note, C doesn't really make provisions for writing "close to the
> machine" code any better than Fortran.

You are incorrect, I'm afraid.  What Fortran construct corresponds
to "volatile", which is in essence a model for a memory-mapped device
register?

Re: kernel-2.2.1-undefined references.

[Benjamin Scherrey]

    Geez people lighten up! This is worse than the C++-in-kernel thread that
occurs in the linux list. I think we've identified what the issue is here
(right?). Now - who's the guy who makes the decision (Jeff?) and what's it going
to be?

    I think Linus and company are slightly aware of what the egcs team has
provided and I don't think your recitation was intended to clarify his mind. This
"discussion" is only wasting my time and every one else's who attempts to keep up
with this list.

    If the issue isn't completely understood by both sides yet perhaps Linus could
provide a couple of source examples (if he hasn't already - I haven't bothered to
read every tirade, err message in this thread) who's behavior has changed and an
egcs maintainer could either say "it will be fixed" or, at least, explain how one
might predict whether or not the code will inline as expected. The last I heard,
these computer things were still deterministic and truly random results were still
hard to generate...

    flame out,

        Ben Scherrey

craig@jcb-sc.com wrote:

> Which means, what, exactly?  That you therefore can claim some kind
> of *ownership* of the exact behavior of gcc in the presence of
> all sorts of extensions, regardless of the degree to which they're
> clearly specified and documented?  Sorry, you *should* know better.
>
> >There were tons of code generation bugs over time, but hey, I _expect_
> >bugs, and while compiler bugs are sometimes really hard and nasty to find,
> >I don't complain too much: I report them, and I tell people not to use
> >certain versions. I may be grumpy for a while because I spent ages looking
> >at a bug that didn't turn out to be mine, but I never get the feeling that
> >I should really dislike the compiler people.
>
> Given how you've treated the egcs developers lately, for daring to:
>
>   -  Offer you a free compiler
>
>   -  Offer you free upgrades
>
>   -  Offer you free responses to bug reports
>
>   -  Offer you free bug fixes
>
>   -  Offer you free improvements to unclear documentation
>
>   -  Offer you free advice as to how to improve your code to make
>      it more immune to likely changes to egcs code development
>
> I think we're *all* grateful you don't feel you should actually
> *dislike* us.

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> No, I heard more than that. Such as, the compiler may opt to make a function
> into an inline based on optimization. Which scares the hell out of me, too.

Get used to it; almost every compiler will do this at high levels of
optimization.

> The argument, though, should be telling you that basing a C compiler
> front-end on top of a C++ engine is going to become more and more risky.

It has nothing to do with C++.  Fortran compilers are the most aggressive
at doing major restructuring of this form.  If anything, C++ compilers
do *less* of it.  The reason is the compiler writers are spending so
much time getting the semantics right that they have no time to do much
optimization.

> There once was a time when there was a tight correlation between the C code
> and the assembly.

Turn off -O if you want that.

> I like Per's comments about not being able to produce a compiler that behaves
> like Linus would want.

Would you be willing to accept 50% slower code for tighter control?
(You could get the 50% back by personally directing every compiler
transformation, but you'd have to get them all right and then redo
them every time you change any of the code).

Re: kernel-2.2.1-undefined references.

[Patrick Grueger microTOOL]

>In that case, could there not be a magical Linus-Special Inline
>such as __inline or otherwise, that'd be Just Like inline, but 
>Better(tm)?
like __forceinline in MSDev6.0;-)

Re: kernel-2.2.1-undefined references.

[H. Peter Anvin]

> 
> Of course inline is supposed to work, but as you've heard this is
> largely a question of *reliably* generating correct code and as in the
> past *your assumptions* about what the compiler should be doing rather
> than objectively documented behavior.  The compiler may not be living
> up to your expectations, and I know that it hasn't in the past, but
> just as in some of those cases (e.g. the asm clobbering issue or the
> inline+label addresses), the problem is that you are relying on
> behaviour that is either undocumented and thus not guaranteed or
> falling between the cracks of the implementation.
> 
> I think this is a case where the documentation is misleading.  It does
> suggest that inlining is not guaranteed, but IMO not as prominently as
> it should.  That is what you've been bit by, *not* a guarantee that
> isn't being honoured.
> 

On another note, however, it really sucks to have to rely on macro
expansion -- it wrought with pitfalls, and the syntax is different in
the most bleacherous manner (requiring \ at the end of each line.)  It
is much nicer to have the compiler check the syntax properly, but it
really requires it to work right.  Oh yes, __builtin_constant_p()
really, really ought to work properly in an inline...

	-hpa

Re: kernel-2.2.1-undefined references.

[Joe Buck]

Linus writes, in response to a suggestion to use a special feature of
macros:

> Why don't you just remove "inline" completely, then?
> 
> It's apparently ok to break documented and existing behaviour of "inline". 
> Go read the gcc documentation about "extern inline", the whole thing is
> _designed_ to be a much more readable form of #define. 

Hmm.  Linus does seem to have a point here.  See the node "Inline"
in 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."

This seems to be a fairly strong promise that the function is guaranteed
to be either inline or to come out undefined (unless there is a second
non-extern-inline definition).

Many people have been answering based on general compiler principles
rather than by looking at the promises made in the gcc documentation for
an *extension*.

Re: kernel-2.2.1-undefined references.

[craig]

>On 9 Feb 1999 craig@jcb-sc.com wrote:
>
>> >Why don't you just remove "inline" completely, then?
>> 
>> Because it works just fine, and as documented, for 99.9999% of the
>> uses to which its put in code compiled by gcc?
>
>Right. So why break it then?

By your apparent standards, it always *was* broken, because inlining
didn't always happen.

Yet, as I said, even then, it works just fine, and as documented,
for 99.9999% of the uses to which it is put in code compiled by gcc.

(That's not surprising, since gcc is, generally, based on standards
such as ISO C, which presumably make it much clearer that "inline"
is, like "register", a mere hint.)

Sorry you recently got bit by this, though.  That happens quite often
when using tools as complex as gcc, I'm afraid -- review all the
egcs- and gcc2-related discussions regarding 64-bit alignment of
REAL*8 (aka `double') on PPro and PII chips that have gone on
even since we *thought* we had this "fixed" in a long-ago version
of g77 based on gcc 2.7.something.  As with your situation, what
we thought "worked" just happened to not fail, and getting it
to truly work properly is much more difficult, politically as well as
technically, than we ever thought.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

Hey, wow, I actually agreed with everything Craig said. 

In article < 19990213001623.23023.qmail@deer >,  <craig@jcb-sc.com> wrote:
>
>The best thing gcc can do to help *everyone* is to be, generally,
>fairly predictable when it comes to making implementation decisions
>that aren't clearly wrong.
>
>And *that* is what Linus has been asking for all along, and what I've
>seen, I think, all the pertinent gcc developers agreeing to, even
>while they're saying "but don't *depend* too much on this".

Indeed. Right now, to me, it seems like there is _no_ sane way to do
what I want to do, and rely on what gcc will actually do. This is the
result of having a bad definition of what things do.

This is why I objected to the early suggestion to just make the
documentation even more uncertain on exactly what "inline" did.  I think
the problem in the first place was documentation that said "almost" and
"mostly" and "maybe" and "in a blue moon". 

When you have documentation like that, you can't but rely on
implementation, because the documentation doesn't actually give you
anything to depend on.  And then we end up in a situation where people
like me depend on implementation and implementors point fingers at bad
documentation. 

Testability goes to hell too. 

And yes, it's made worse by the fact that there _are_ actually sane ways
to do _exactly_ what I want to do, but they don't work with older
versions. People suggest I use #ifdef's etc, but that doesn't exactly
help testability either, and makes one of the points of using inline
functions go away completely - readability.

>It is *incredibly* challenging to design a language that allows
>programmers to specify just what they want to have happen *and*
>also allow them to specify exactly how the compiler is to make
>some unspecified thing happen.
>
>I call the former SWYM -- "Say What You Mean" -- defined as a
>specification from which not one single expression, operator,
>variable, whatever, can be removed without making the specification
>inviable.  I call the latter DWIS -- "Do What I Say" -- defined as
>a specification of how resources are to be employed, step by step,
>with as little information on what is actually the desired output
>as possible.

I guess I count as a DWIS person - I think that just is what C is
designed for.  In systems programming, you just can't let the compiler
do too many of the decisions for you. 

Obviously, C++ is very much a SWYM environment, and the compiler copes
best it can.  That's one of the reasons we very quickly discarded C++ as
a kernel language (we used to compile the Linux kernel with C++ a
_loong_ time ago, back when people still thought OO was a sexy
"must-have"). The compiler was just too unpredictable in many ways.

>In the meantime, it'd be a good idea to decide which direction
>gcc should go, which I think the industry as a whole has concluded is
>"SWYM", since that's where C's going, and stick with it, completely,
>or nearly, ignoring proposed extensions representing the other side,
>because C, as a language, cannot support both paradigms (it can
>barely support one).

I would hope you don't propose to go too far. In many areas, the main
strength of C is still as a reasonably portable low-level programming
tool that doesn't get in your face.

For SWYM, we already have things like visual basic,

		Linus

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> From: Joe Buck <jbuck@Synopsys.COM>
> To: leei@ai.sri.com (Lee Iverson)
> Date: Mon, 8 Feb 99 17:40:44 PST
> Cc: jbuck@Synopsys.COM, torvalds@transmeta.com, ross.s@ihug.co.nz,
>         egcs@cygnus.com, hpa@transmeta.com

> It might be appropriate to generate an error, not a warning, if
> "extern inline" fails to inline, since it is clear from the
> documentation that this is not a mere hint.

No, it is not appropriate.  First, from the doc:

  The way to use it is to put a function definition in a header file
  with these keywords, and put another copy of the definition (lacking
  @code{inline} and @code{extern}) in a library file.  The definition
  in the header file will cause most calls to the function to be
  inlined.  If any uses of the function remain, they will refer to the
  single copy in the library.

This clearly states that we expect some uses won't use the extern
inline, what would be the point of putting in a library definition if
we got errors on all translation units that didn't inline?

Second, we want forward compatibility with the next ANSI standard for
C, that in that standard, inline will be a pure hint (or if not that
one, in the one after it).  An error message is a motion in the wrong
direction and a motion in the wrong direction is bad.

Re: kernel-2.2.1-undefined references.

[Joern Rennecke]

> >No.  ANy code which depends on a function being inlined for correctness
> >is broken.  That's it, there's no if and's or but's about it.  The linux
> >kernel depends on certain functions being inlined and is therefore broken.
> 
> Why don't you remove "extern inline" completely, then? It serves no
> useful purpose, it seems.


The safe way to use "extern inline" is to have the "extern inline" in
a header file, and have a function implementation in a module or a library
so that any uses that couldn't be inlined can be resolved by the linker.

----- End of forwarded message from Joern Rennecke -----

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> > Remember, we are not talking about ISO C++ here.  We are talking about
> > *C*, and specifically the GNU "extern inline" extension.  So the M to R
> > is the gcc manual.
> 
> I actually did, and while the discussion of "extern inline" strongly
> implies that it is guaranteed behavior, it doesn't *really* come out
> and say it.  There is a hedge above though in the sentence "Note that
> certain usages in a function definition can make it unsuitable for
> inline substitution."  It looks like that is just a hedge on automatic
> inlining, but it is really a hedge on the whole process...

Yes, clearly some functions cannot be inlined.  The compiler developers
cannot promise the impossible.

The language implies that if inlining fails you'd just have an external
reference, meaning you'd have an undefined symbol if there is not a
second, non-inline definition.

> I do think that the language is ambiguous and definitely suggests
> something that the compiler cannot guarantee.  That's why I've
> submitted a patch to egcs-patches to clarify this:
> 
> 	  http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00176.html

It might be appropriate to generate an error, not a warning, if
"extern inline" fails to inline, since it is clear from the documentation
that this is not a mere hint.

Re: kernel-2.2.1-undefined references.

[Bob McWhirter]

On Mon, 8 Feb 1999, Linus Torvalds wrote:

> On Mon, 8 Feb 1999, Lee Iverson wrote:
> > 
> > It occurs to me that we do, in fact have an acceptable method of
> > *guaranteeing* inlining of a *function* in gcc.  That is a combination
> > of a macro and the "Statement Expression" extension.
> 
> Sure. 
> 
> Why don't you just remove "inline" completely, then?

I'm probably coming into this waaaay too late, but I thought the
standards (C++ and C9X?) had definite things to say about what
'inline' should mean; that is, that it was a hint or recommendation
to the compiler, but by no means a direct imperative.

It seems that a guaranteed forced 'inline' would be non-conforming.

In that case, could there not be a magical Linus-Special Inline
such as __inline or otherwise, that'd be Just Like inline, but 
Better(tm)?

As far as egcs breaking things, I thought we pretty much expected
that (it's half the fun), and rely on gcc2 if we needed actual 
determinism. ;)

Feel free to ignore.

-Bob

--
Bob McWhirter    Shop Foreman, Decision Scientist, Cat Juggler 
Werken Digital   A division of the Benjamin J. Werken & Sons Company
bob@werken.com   http://www.werken.com./

Re: kernel-2.2.1-undefined references.

[Jeffrey A Law]

Opps, cc to egcs was botched.

---

To: torvalds@transmeta.com (Linus Torvalds)
cc: submit-linux-egcs@transmeta.com
Subject: Re: kernel-2.2.1-undefined references. 
Reply-To: law@cygnus.com
In-reply-to: Your message of 12 Feb 1999 19:40:35 MST.
             < 7a203j$9cf$1@palladium.transmeta.com > 
Date: Fri, 12 Feb 1999 12:48:32 -0700
Message-ID: <9186.918848912@hurl.cygnus.com>
From: Jeffrey A Law <law@hurl.cygnus.com>


  In message < 7a203j$9cf$1@palladium.transmeta.com >you write:
  > In article < 19990212031118.4271.qmail@deer >,  <craig@jcb-sc.com> wrote:
  > >
  > >The buglet in gcc has, I gather, already been fixed.
  > 
  > Yes. 
  > 
  > The sad part is that the bug was fixed several months ago. It was just
  > re-introduced _again_ last week.
No.  This is not what happened.  Please don't state this as a fact since you
do not know the facts.  If you would like to know the facts, then ask.

  > It's not at all buggy, it just assumes that the compiler does something
  > reasonable. 
No.  ANy code which depends on a function being inlined for correctness
is broken.  That's it, there's no if and's or but's about it.  The linux
kernel depends on certain functions being inlined and is therefore broken.

jeff

- --LAA12836.918848952/neon.transmeta.com--


------- End of Forwarded Message

Re: kernel-2.2.1-undefined references.

[Marc Espie]

You could *at least* acknowledge that you read the original documentation 
wrong, and that you relied on your interpretation of it...

You have stated repeatedly that egcs broke a *documented* feature, and we
have been repeatedly telling you that it was undocumented, and that your
interpretation was wrong. The *implementation* worked in the way you described,
but the *interface* did not !

Is it *that* hard to state publically ?   Nowhere in *any* of your messages
did you even *hint* that you may have made a small misinterpretation.

Afterwards, we can all go back to serious coding, like getting the documentation
straighter, or fixing egcs to get more compatible with old gcc's ways (which
is *the* current problem. but stop referring to it as `breaking old documented
behavior, which is getting on everybody's nerves, haven't you noticed ? :) )

Get your gripes straight, please. We all know that you have been having trouble
with egcs in the past, this is no reason to be downright insulting to people
who have been *very* responsive to motivated queries, as I can attest from
the OpenBSD side of the free world.

(kuddoes to Mike, Jeff, Kaveh, Zack, and the rest).

Re: kernel-2.2.1-undefined references.

[Gerald Pfeifer]

On Tue, 9 Feb 1999, Paul Derbyshire wrote:
> At 07:20 PM 2/8/99 -0800, you wrote:
>>  The way to use it is to put a function definition in a header file
>>  with these keywords, and put another copy of the definition (lacking
>>  @code{inline} and @code{extern}) in a library file.
> *ahem* There are some of us with mail clients that don't know how to
> render email with these formatting codes. (What is it anyways?

It is texinfo, the format most gcc docs are written in. Just check out
the *.texi in your egcs distribution. As this is a technical list, source
for sure is appropriate.

> Holy sh!t ... er... Is that really Linus Torvalds himself?

<rant>Come one, that guy is not holy nor extraterrestial. What's
the purpose of posting that to the list?</rant>

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Lee Iverson wrote:
> 
> I actually did, and while the discussion of "extern inline" strongly
> implies that it is guaranteed behavior, it doesn't *really* come out
> and say it.  There is a hedge above though in the sentence "Note that
> certain usages in a function definition can make it unsuitable for
> inline substitution."  It looks like that is just a hedge on automatic
> inlining, but it is really a hedge on the whole process...

And while you're at it, what's your definition for "sex"?

It's ugly in politics, it's ugly in technican discussions. Don't hide
behind technicalities.

		Linus

Re: kernel-2.2.1-undefined references.

[craig]

>Christ Craig, give it a rest. This is a dead horse you're beating. Some
>reasonable sane and rational suggestions for solving the problems both with
>Linux and egcs have appeared; someone's found that a conditional compile
>can be used to make the extern inline thing compile and work on every gcc
>by either using __builtin_return_address or the label hack; Linus has said
>the panic code isn't too critical anyways and has apologized for some of
>the tirades earlier in the week; and it seems to be high time this issue
>was let drop on the list; yet I keep seeing more tirades from you every few
>minutes to an hour.

Yet, later, you followed up one of my "tirades" offering your own
opinions.  I guess it's okay if I don't respond to that?

Be aware that __builtin_return_address probably will stop working
someday in gcc.  Read my latest tirade to get an idea of why that is.

>BTW, did you know that your ISP's mail server was bouncing mail
>inexplicably all afternoon? Was bouncing messages with "Service
>unavailable". Never heard of downtime causing mail to bounce before;
>usually it's deferred. You should have a few stern words with your ISP's
>customer service reps about this; if the downtime had been much longer the
>bounces would have caused yo to be removed from this list and any others
>you're on more than likely. They should just defer the mail.

Do you have any bounced email to forward along, so I can see what
was actually happening?  That's the first thing my ISP would
ask for, probably.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

This response is too long, but it's the last I'll say on the
subject.

In message < 79sgd8$p7p$1@palladium.transmeta.com > you write:
> In article < 19990210133236.30212.qmail@deer >,  <craig@jcb-sc.com> wrote:
> >>On 9 Feb 1999 craig@jcb-sc.com wrote:
> >>
> >>> >Why don't you just remove "inline" completely, then?
> >>> 
> >>> Because it works just fine, and as documented, for 99.9999% of the
> >>> uses to which its put in code compiled by gcc?
> >>
> >>Right. So why break it then?
> >
> >By your apparent standards, it always *was* broken, because inlining
> >didn't always happen.
> 
> No.
> 
> gcc _did_ use to always inline if it at all could do so.  There were
> cases that made it unable to inline, simply because the code itself was
> not conducive to inlining.  Those were _technical_ reasons for not
> chosing to inline something, and completely and utterly understandable. 
> 
> For example, not inlining a recursive function is just obviously the
> right thing to do (yes, in theory you could try to make it iterative,
> but if the programmer gave the compiler a recursive function then it's
> the _programmer_ who is responsible for it, and nobody really expects
> the compiler to do miracles).

And that was the case here.  The problem you faced was *not* due to
any artificial limit arbitrarily imposed by the compiler but a
technical limitation that was discovered in which gcc/egcs was
generating bad code when inlined code used computed jumps.  The test
to disable inlining in this case was casting too wide a net...  See
Richard Henderson's fix:

	http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00172.html

> It used to be a feature you could depend on.
> 
> The change broke that.

This was never a feature you could blindly depend on and -Winline is there
for the simple reason that it can fail when the programmer might not expect
it to. This is a technical issue, and always was.  You were the one who
turned it into some sort of Jihad and started insulting people
(although some of my friends were quite impressed that I had been
personally insulted by Linus Torvalds, I wasn't too fond of it).
For this particular case, the bug/shortcoming has been fixed, but that doesn't
change the fact that the interaction between certain coding structures and
inlining is fragile.  Your mistake was and still is in assuming that it isn't.

> Yes, the documentation had hedges to handle the real cases (like
> recursion etc) where inlining just isn't feasible, but the fact that it
> hedged its bets doesn't change the fact that people like me used to be
> able to rely on the compiler to do what it was asked to do.
> 
> If it was a case of "oh, gcc used to have a 50-50 policy on when to
> inline, and the change made that a 40-60 policy", then it would have
> been much more palatable. But it wasn't. It was a case of 100% success
> being turned into "I wonder what the hell they'll break next time
> around". 
> 
> Repeatability is good.  Random changes that break existing behaviour for
> no technical reason is bad. 

That's where you are mistaken, this was a "real" case.  I'd have to side with
the point of view that says if you can't reliably generate good code then the
best "fix" is to disable the feature.  That was the case here, the only
problem was that *you* weren't prepared to recognize and deal with the
failure.  If, in the future, egcs developers discover that label
addresses cause bad code to be generated in many circumstances, then
that alone would justify turning off inlining in their presence, even
if those don't include the ones you are relying one.  Ideally, bugs
get fixed, but you know as well as I that sometimes they just get
papered over until they are fixed.  You do the same thing, I've seen
it in action.  Don't impugn the motives of other developers for that.

Get over it.  EGCS *is* a very reliable compiler, but one under very
active development.  Backwards compatibility has *never*, to my
knowledge, been gratuitously broken.  There have been bugs that made
it fail and there have been incompatibilities justified by sound technical
reasoning.

The problem here was primarily with your reliance on a particular
interpretation of a feature which is documented to be unreliable.  If
a previous version of the compiler permitted a use which leads to
broken code (inlining with computed gotos), then there was sound
technical reason to disable it.  And that should be as obvious to you
as anyone else.  The fact that you went off half cocked without even
seeking an explanation doesn't reflect very well on you.  And neither
does your insulting everyone who has disagreed with you.

Time for all of us to get back to coding.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Mike Stump wrote:

> > Date: Mon, 8 Feb 1999 12:15:40 -0800 (PST)
> > From: Linus Torvalds <torvalds@transmeta.com>
> 
> > I'm not trying to be unreasonable. I'm just saying that if there is
> > a function that is marked inline that can be inlined, it _should_ be
> > inlined, because the compiler _never_ knows better than the
> > programmer.
> 
> Let me provide a counterpoint.  In C++, it is common to have
> templates.  In templates, it is common to have lots of small,
> sometimes, really small functions.  Sometimes, programmers put
> `inline' on them.  The C++ standard says they `inline' by default on
> those defined in the class body, this also is common.

That's fine. I'm actually not asking that _all_ "inline" keywords actually
be honoured, I'm asking that there be some way of forcing gcc to honour
it, the way it used to do. 

In particular, "extern inline" has basically been documented to be a macro
(some Clintonesque arguments to the contrary notwithstanding), and does
not make sense to not inline - the documentation even says so. If I have
to add an "extern" to force the inline, that's fine.

Removing features without giving a reasonable way of doing the thing that
gcc has successfully been doing for 8 years is not reasonable.

Codifying the fact that if you really _rely_ on inlines, do so with an
"extern inline" is ok would be very reasonable. Maybe you could even say
that "extern inline" is honoured even when not optimizing.

> I prefer to follow the standard where it says that inline is a hint,
> and only a hint.

You also seem to prefer breaking documented behaviour.

You also seem to want to ignore the knowledgeable user that knows, for
example, that yes, this is a frigging big inline, but it's only used in
one place, and it's inline in order to make the code more readable, but I
really want to have the compiler inline it for me to make the code faster. 

Why not just say that for "extern inline" there are NO artifical limits,
because the damn documentation _tells_ you that "extern inline" is a gcc
extension to the language that creates a macro-like function. 

Instead of breaking stuff that used to work. 

		Linus

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

In article < 9211.918849009@hurl.cygnus.com >,
Jeffrey A Law  <law@hurl.cygnus.com> wrote:
>
>  In message < 7a203j$9cf$1@palladium.transmeta.com >you write:
>  > 
>  > The sad part is that the bug was fixed several months ago. It was just
>  > re-introduced _again_ last week.
>
>No.  This is not what happened.  Please don't state this as a fact since you
>do not know the facts.  If you would like to know the facts, then ask.

I was _there_, Jeff. The bug got introduced in the gcc-2.8.x development
tree, and we had this same discussion - it just happened to be more
private. The bug was fixed back then by Richard Henderson, he just
didn't get permission to check in his fix.

The bug then re-appeared in egcs apparently simply due to a merge with
gcc-2.8.x, exactly because rth hadn't gotten his fix in originally.

>  > It's not at all buggy, it just assumes that the compiler does something
>  > reasonable. 
>
>No.  ANy code which depends on a function being inlined for correctness
>is broken.  That's it, there's no if and's or but's about it.  The linux
>kernel depends on certain functions being inlined and is therefore broken.

Why don't you remove "extern inline" completely, then? It serves no
useful purpose, it seems.

		Linus

Re: kernel-2.2.1-undefined references.

[Bruce Stephens]

Jeffrey A Law <law@hurl.cygnus.com> writes:

> To: torvalds@transmeta.com (Linus Torvalds)

[...]

>   > It's not at all buggy, it just assumes that the compiler does something
>   > reasonable. 

> No.  ANy code which depends on a function being inlined for
> correctness is broken.  That's it, there's no if and's or but's
> about it.  The linux kernel depends on certain functions being
> inlined and is therefore broken.

In a strictly literal sense, I think you're right.  Perhaps this is
better reported as a documentation bug rather than a compiler one.

I think it's unfair on Linus to criticize him, however.  He's made a
reasonable interpretation of what the documentation says (it's how I
read it, too) and this interpretation holds for more than one version
of the compiler.

His interpretation also strikes me as describing a useful feature: a
macro dressed up as a function.  Of course there'll be examples of
functions which wouldn't be inlineable, but surely when what I've got
is basically a macro, it would be handy to be able to use function
notation (in order to get argument copying, type checking, and so on)
and to know that the thing will be treated as described in the
documentation (but with the offending "most" replaced with "just about
all"---with the exceptions being indirect calls and the like, I
guess)?

I confess I don't understand why there might be cases where functions
*must* be inlined for correctness, but performance matters too:
functions are more readable than longish macros with silly temporary
variable names and things---people (for whom portability between
compilers isn't critical) ought to be encouraged to use more readable
mechanisms where possible, and providing suitable mechanisms is surely
a Good Thing.  And, I imagine, in a kernel sometimes performance can
affect correctness (though I may be quite wrong---I've lost the
mention of which functions in the kernel were hit by this, and the
"extern inline"s I can spot look like they shouldn't be critical).

Re: kernel-2.2.1-undefined references.

[Matthias Urlichs]

Hi,

Linus Torvalds:
> If you guys even had a _technical_ reason for changing things, I'd
> understand. As it is, I really don't look forward to working with people
> who want to change compiler interfaces on a day-to-day basis.
> 
The current limiting code was, AFAIK, put in because excessive inlining
caused egcs (more specifically, g++) to require a somewhat ugly amount of
swap space. But somebody else can probably answer that question better than
me.

Anyway, it's been documented for some time that inline isn't always
honored. Whether that happens in 10% or in 0.0001% of the cases which are
relevant for the Linux kernel is, IMHO, somewhat non-interesting.

Anyway^2, fixing the problem is easy, all we need to do is to decide on a
"correct" way to do it. (Famous last words, I know. On the other hand,
neither 'side' of this debate needs the ego boost provided by Having Been
Right All Along, so...)

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
I haven't got time to chat to undersecretaries, permanent or otherwise.
                                -- Pertwee, DOCTOR WHO AND THE SILURIANS

Re: kernel-2.2.1-undefined references.

[David J. Dooling]

   >In article < 19990210133236.30212.qmail@deer >,  <craig@jcb-sc.com> wrote:
   >>>On 9 Feb 1999 craig@jcb-sc.com wrote:
   >>>
   >>>> >Why don't you just remove "inline" completely, then?
   >>>> 
   >>>> Because it works just fine, and as documented, for 99.9999% of the
   >>>> uses to which its put in code compiled by gcc?
   >>>
   >>>Right. So why break it then?
   >>
   >>By your apparent standards, it always *was* broken, because inlining
   >>didn't always happen.
   >
   >No.
   >
   >gcc _did_ use to always inline if it at all could do so.
   
   False.  gcc *never* inlined 100% reliably.  It might have tried,
   and succeeded often enough, but other times, it just generated
   bad code, or ran out of memory, or similar.

ENOUGH!!!!!!!!!!!

This whole thread only serves to fill all our mailboxes with a bunch
of name-calling and nitpicking.  It does not help the development of
gcc or linux (I assume the reason we are all subscribed to this
listserv is to _help_ the development of gcc, no?).  It is the
software development equivalent of ``my dad can beat up your dad!''.

Basically (without all the name-calling), the developers of egcs found
that combining two gcc extensions did not produce reliable code.  So,
they took the easy fix: don't allow them to be combined.  This broke a
significant amount of code for one user, Linus (granted he is not just
_any_ user, nonetheless ...).  I am sure other people who depend on
these gcc extensions will also feel the pinch.  This is all fact,
everything else that has been said is superfluous.

That being said, is there anything we can do together to improve the
situation for all of us?  Obviously the combination of these
extensions worked sometimes.  Is there any way to find out when it
works and when it doesn't?  It should be a deterministic problem, no?
Perhaps Linus has some cases in his code where he knows it works.
Perhaps other has incidences where it doesn't.  Is there not time to
address these issues now?  Can it be put on the TODO list?  Can we at
least agree on how to warn/error when gcc can't comply with what the
programmer wants?  There has to be something that can be done to make
the compiler (and the atmosphere on this thread) better.

Admittedly, I have not the knowledge nor the expertise to investigate
these options myself (I am but a lowly chemical engineer).  I
apologize for this (my only intention is to help).

Let's turn this thread around, discuss some specifics, and get
something done.

DAVID?

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

In message < 199902090116.RAA15478@atrus.synopsys.com > you write:
> 
> > I've yet to see *any reference* to the claim that it is *documented*
> > that the inline declaration *guarantees* that the function will always
> > be inlined.  Even with extern.  That was your assumption, reading
> > between the lines...
> 
> RTFM.
> 
> Remember, we are not talking about ISO C++ here.  We are talking about
> *C*, and specifically the GNU "extern inline" extension.  So the M to R
> is the gcc manual.
> 
> We may have an issue later on with C9X, which may define "extern inline"
> to mean something different.

I actually did, and while the discussion of "extern inline" strongly
implies that it is guaranteed behavior, it doesn't *really* come out
and say it.  There is a hedge above though in the sentence "Note that
certain usages in a function definition can make it unsuitable for
inline substitution."  It looks like that is just a hedge on automatic
inlining, but it is really a hedge on the whole process...

I do think that the language is ambiguous and definitely suggests
something that the compiler cannot guarantee.  That's why I've
submitted a patch to egcs-patches to clarify this:

	  http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00176.html

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

In message < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu > you write:
> 
> ENOUGH!!!!!!!!!!!
> 
> [deleted]
> 
> Let's turn this thread around, discuss some specifics, and get
> something done.

Already done and in the CVS tree thanks to Richard Henderson.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Theodore Papadopoulo]

Matthias Urlichs:
> The current limiting code was, AFAIK, put in because excessive inlining
> caused egcs (more specifically, g++) to require a somewhat ugly amount of
> swap space. But somebody else can probably answer that question better than
> me.

	No, to my knowledge the patch that limits the size of inlined 
function is not yet in the egcs sources. The current source still 
does not limit the size of function marked as inline (I guess that 
extern inline functions are treated the same way). Note that function 
not marked as inline can be inlined by the compiler and that there is 
a size limit for those (but that's not the case discussed in this 
thread).

AFAICT, the patch has not yet incorporated precisely because of concerns about:
- having understandable rules (how the limit is expressed and when it 
  is in effect.
- breaking the current behaviour of gcc as little as possible.

This is clearly an example showing that egcs people are not changing 
things without being convinced that they do the right thing.

The discussion thread subject was "g++ memory bug" for those that are 
interested.

The current list of reasons for which a function would not be inlined
has been given by Richard Henderson in a previous message of this 
thread.

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: kernel-2.2.1-undefined references.

[craig]

>In article < 19990212031118.4271.qmail@deer >,  <craig@jcb-sc.com> wrote:
>>
>>The buglet in gcc has, I gather, already been fixed.
>
>Yes. 
>
>The sad part is that the bug was fixed several months ago. It was just
>re-introduced _again_ last week.
>
>>						  I haven't
>>gotten the impression the underlying bug(s) in Linux have, or
>>will, get fixed.
>
>Craig, have you actually bothered to look at the Linux use of "inline"
>at all? I don't think you have, and you're just spouting sh*t on the
>list. 

I realize you think that.  That's because you're rather uninformed,
or intentionally forgetful, about what has really been going on here,
and prefer to insult others than to take responsibility for mistakes
committed (repeatedly) on your end.

>It's not at all buggy, it just assumes that the compiler does something
>reasonable. 

No, it assumes that the compiler does something *some* people consider
reasonable, but others don't, and which is not *documented* by the
compiler to do any particular thing, implementation-wise.

>In particular, there are two kinds of "inline" in the kernel.  There's
>the "oh, I'd like to get this inlined" kind of inline, and there's the
>"consider this a macro" kind of inline. 

In other words, the kernel makes two uses of "inline", one that is
correct, the other that is incorrect.

>Please go and actually look at the sources you complain about.  I'm not
>an unreasonable person, I just get DAMN irritated when the same bug
>shows up twice in gcc, and people have a hard time even admitting it is
>a bug (I think the post by you is the first one that actually calls it a
>"buglet", finally - it's a bug, and yes, it was small, but by golly it
>was HARD to get people to even acknowledge it as one). 

First, I based my comments on what *you* were saying when *you* were
slinging mud at the egcs developers, the decisions they were making,
and the help they were offering you.

If you had wanted us to look at any sources, *you* should have posted
the relevant bits here first, perhaps in place of mud-slinging, which
you continue to prefer to engage in.

>Basically, Linux _does_ already use the "inline as hint" mentality: we
>have tons of functions that are marked "static inline" or just "inline". 
>Some of those functions are quite large, and some of them actually only
>make sense inlining on an alpha or other sane architecture that has tons
>of registers: and I'd be very happy if gcc actually decides at some
>point that "oh, this function just adds too much register pressure to
>make sense to inline on an x86". 

Fine and dandy.

>There's another class of "inline" usage, though - the "use as macro"
>class, because inline functions are often a _lot_ more readable than
>macros are, and you get tons of other advantages (the compiler does the
>argument copy so you don't have side effect problems, and often most
>importantly you get argument type-checking with good error messages with
>inline functions that you wouldn't get with a macro).  Those "use as a
>macro" inlines are marked, for the edification of gcc, as "extern
>inline". 

Which is incorrect, if the code actually *depends* on inlining
actually happening, as the documentation should have made clearer,
but most everyone already knew.

>Guess what? A lot of them _used_ to be "static inline", because "static
>inline" is safer (it works as expected in the presense of the address-of
>operator, and yes, if the compiler refuses to inline the thing because
>it's not optimizing, it will still create the function for you).  Most
>of them were _changed_ to "extern inline" mostly due to the gcc
>documentation.

Mostly due to an *incorrect reading* of the gcc documentation, which
didn't help things.

>So Craig, go and look at some of those "extern inline" functions. 
>Instead of just spouting crap on the mailing list without obvously never
>having even _looked_ at the problem.  All of them are _extremely_
>reasonable as far as I can tell - feel free to look for yourself.

More below on your continuing attack on my efforts to educate you
as to proper use of gcc extensions.

>The ones that were bitten by the egcs bug (let's just be honest and call
>it what it really was)

I have concluded that *you* wouldn't know "honesty" if it bit
you in the ass.  You have lied about this before, and you are
continuing to lie about it now.  egcs not inlining an "extern inline"
function is not, never has been, and never will be a bug.  The
*developers* might consider it a bug, in that they'd prefer some
cases be inlined for performance reasons, but to the user, it is
*never* a bug in the sense of violating the "contract" the compiler
makes with its users, in the form of an explicit language
specification.

In that sense, it's what I call a "buglet", meaning, not necessarily
a high-priority bug -- not a violation of the "contract", or
specification, of how the compiler behaves in terms of implementing
the language it compiles.

In writing the g77 documentation, I tried to make the distinction
between promises made on behalf of the GNU Fortran *language* and
the behavior of the current GNU Fortran *compiler* as clear as I could.

If, as a programmer, I don't see that clear a distinction in a product's
documentation, I assume *fuzziness*.

It's been *your* error that you've assumed that any behavior you observe
and which the gcc documentation doesn't clearly say might change will
therefore be promised for all of eternity.  That's a *very* frequent
error, but rare is the person who insists on insulting those who
try and point it out to him, especially as repeatedly and as nastily
as you've done.

>were so small that it would have been completely
>unreasonable for any good compiler to not inline them.  They were
>essentially two assignments and a copy, they just happened to have the
>address-of-label thing in some debugging code (because all other gcc
>methods of getting the current PC have been buggy at various points). 

The only reasons it should have mattered to you that inlining did
not happen are that you didn't get the performance you want, or
the generated code was actually wrong.  Neither was the case.  Therefore,
if the overall result was that *your* code broke, it was not *egcs*
that broke it -- it was a change to egcs that triggered a long-hidden
bug in your code.  Please stop saying things like "this change broke
egcs", as that's a lie.

>Basically, Craig, just come down from your ivory tower and look at the
>code, and I'd be surprised if you didn't agree with me that Linux
>"extern inline" usage actually makes sense if you were to just spend a
>_small_ amount of time actually looking at it instead of spouting off
>without knowing what's up.

Okay, Linus, now that you've *totally* destroyed any and all credibility
you've *ever* had with me, and converted me from promoting your
abilities, and Linux, to friends and neighbors to warning them away
from anything you touch, I'll enclose a copy of some emails sent *six
months* ago on a closely-related issue.

I want you to read these emails *very* carefully, and then come back and
explain exactly how you still believe I'm simply up in an "ivory tower",
have never had a "look" at code *you* have not (to my knowledge)
offered here, and how I should still agree that Linux' use of
"extern inline" as "guarantee me inlining" makes sense.

(For *other* readers, who *are* allowed to not bother reading the
emails quoted below: the summary is, this problem came up before,
was specified as being related to Linux, and was *thoroughly* and
*completely* explained as being the result of a combination of
poorly-specified extensions, inadequate documentation, and Linux'
inappropriate reliance on the behavior of extensions.  Further,
viable alternatives were proposed.  Apparently that did no good
then, though I'm willing to take the blame for not fixing the
gcc docs myself, and there is plenty of reason to assume all this
verbage will do no good now.)

        tq vm, (burley)

P.S. Yes, folks, I realize that Linus almost certainly won't bother
actually reading the below, as he's already cast my posts on this
topic as "silly" and so on.  I'm writing all this for the public
record, basically: I want it clearly on record that Linux developers
(which I assume included David Miller, involved in the emails below)
were *warned* about this problem, told to change their code and
how to properly read the documentation *months* ago, that Linus
himself continually and repeatedly ignores the same advice given
now and insists on continuing to tell the lie that egcs is the
source of the problem.  It does *not* matter to me whether Linus
ever "gets" it, all things considered.


>Date: Tue, 28 Jul 1998 11:36:27 -0400 (EDT)
>From: Craig Burley <burley@gnu.org>
>To: davem@dm.cobaltmicro.com
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
>        rth@cygnus.com
>Cc: burley@gnu.org
>In-reply-to: <199807281242.FAA31050@dm.cobaltmicro.com>
>	(davem@dm.cobaltmicro.com)
>Subject: Re: inline functions and local labels
>
>>   Date: Tue, 28 Jul 98 08:36:39 EDT
>>   From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
>>
>>   Inlining tells the compiler "for efficiency reasons, I'd like you to
>>   do your best to inline this function", not "even if you do it wrong, I'd 
>>   like you to inline it".
>>
>>Then what does "extern inline" say?
>
>It says "if you can inline this function, great, but even if you can't,
>don't compile it as a separate function".  E.g. if you compile without
>optimization, it doesn't get inlined.
>
>>Forget for a moment what you know about C and compiler implementation
>>details, and all of the issues surrounding this topic.  And pretend
>>for a moment you are a programmer using GNU C to accomplish some task
>>and you wish to express something, and you find that GNU C allows you
>>to express this by saying:
>>
>>extern __inline__ check_a(int a)
>>{
>>	__label__ here;
>>
>>	if(my_test(a) != 0)
>>		printf("Assertion on 'a' failed at %p\n", &here);
>
>(I think that should be `, &&here'.)
>
>>&&here:
>
>(I think that should be "here:".)
>
>>}
>>
>>Can you tell me that this does not seem like a useful construct or
>>feature?  Can you also tell me that this is hard for the person
>>writing such code to understand?  Which behavior of the above function
>>do you deem would be correct in any case?
>
>I'm confused -- what are the choices?  I've already tried to construct
>an example showing the differences, and can't do so without resorting
>to bogosities like having some external code somehow depend upon
>the uniqueness, or value, of labels passed to it as `void *' arguments.
>(See below for an example.)
>
>>It depends, for standard C constructs, I can understand this
>>completely.  For GNU C extensions, we can say whatever we like about
>>semantics wrt. inline functions, and in fact document them.
>
>I think we should first figure out whether the proposed semantics
>make good linguistic sense in the first place.  When I first looked
>into this as a result of this discussion, I *thought* there were some
>very interesting issues here, but so far all I can find is places
>in the gcc docs where we could do a better job clarifying stuff
>most programmers would regard as "natural" for them (and perhaps
>in disagreement with each other).
>
>>This issue is different from most others, because it is an issue of
>>semantics when two different GNU C extensions are used together, so we
>>can define the semantics any way we wish to in such cases.  I contend
>>that the current behavior makes the most sense and is the most useful
>>for users of GNU C (the fact that this behavior has been in known
>>active use for 4 or 5 years is a testament to this!).
>
>I'm still confused as to what the current behavior *is* that is
>being depended upon.
>
>My *guess* is that the current behavior is to try and inline functions,
>which is not always done.  That's what the docs say (especially if you
>read carefully, and between the lines -- they could stand improving
>though).
>
>What exactly *breaks* when code like the examples you post aren't
>actually inlined by gcc?  If it's just that you get unresolved
>references to the externals, well, that's what is *supposed* to happen,
>based on my reading of what `extern inline' means in gcc.
>
>If it's just that when the code doesn't get inlined, the application
>(Linux?) goes slower, well, that's not a linguistic or semantic
>issue -- even if the decision revolves around whether a construct
>like `&&foo' is present.
>
>If that's the case, then it's just a matter of the application no
>longer using `&&foo', or teaching gcc to change that decision again
>(but only when it's safe to do so, to preserve the semantics of
>the function), or teaching gcc a new construct meaning "*inline* this,
>dammit!", such as __force_inline__.  Programmers would be responsible
>for any code-generation bugs resulting from their combining this
>specification with features gcc normally would detect as "I can't
>safely inline this".
>
>
>As far as how hard it is to tell what labels should really "mean",
>here's a contrived example:
>
>#include <stdio.h>
>
>void *
>f (void *arg)
>{
>  static void *x = NULL;
>  void *y;
>
>  if (x == NULL)
>    {
>      x = arg;
>      return arg;
>    }
>
>  y = x;
>  x = arg;
>  return y;
>}
>
>inline int
>myjump ()
>{
>  __label__ bar;
>  void *f();
>  void *foo;
>  static int myval = 1;
>
>  foo = f(&&bar);
>  goto *foo;
>
>bar:
>  return myval++;
>}
>
>int
>main()
>{
>  int i;
>  int j;
>  int k;
>
>  i = myjump();
>  j = myjump();
>  k = myjump();
>  printf ("%d %d %d\n", i, j, k);
>  return 0;
>}
>
>Compiled using gcc 2.8.1 or egcs, without optimization, it prints
>"1 2 3", but with enough optimization to cause inlining, it prints
>"2 4 5" on my RH 4.2 Linux system, probably because the label
>feature is being abused (which gcc doesn't detect, but it does
>print "interesting" warnings about `i' and `j' when inlining, so
>perhaps it could detect this?).
>
>So, depending on the nature of code labels, vis-a-vis whether they're
>static a la variables, or static on a per-copy-of-function basis, seems
>to be unwise.  Even though the gcc docs don't seem to explicitly disallow
>such use, they don't allow it either, and wise programmers wouldn't
>depend on such behavior.  (Not only does the code above not work,
>but neither would depending on the equality of a `void *'-passed label
>determining whether the calling function was the same as some previous
>caller, or some such thing, be wise.)
>
>I suggest we revise the gcc docs regarding labels to clarify that
>any addresses of labels taken within a function during its invocation
>become invalid as soon as the function returns, just as is the case
>for passing `&a' given `int a;' within a function.
>
>We probably also should specify that comparing labels as addresses is
>not a reliable way to determine whether they refer to the same, or
>different, addresses.  That is, &&foo and &&bar, even within a single
>function invocation with foo and bar being labels on different chunks
>of code, could evaluate to equal (gcc could place the generated code
>in the same place in memory, and use state info to disambiguate the
>code at run time), and perhaps even &&foo and another &&foo could
>yield different addresses within the same function (gcc could "flatten"
>programmer-visible state info into distinct code sequences, as long
>as it preserves the correctness of "goto *label;" following each
>corresponding "label = &&foo;").
>
>I think it's okay to allow passing &&label to another procedure, though,
>as long as the lifetime of that argument is the calling function
>invocation's lifetime, and the only use of the argument is to return
>the value back to the function or to print it out (or otherwise make
>it available) for debugging/logging purposes.
>
>Also, perhaps we should clarify the text on "inline" so readers know
>it is never safe to depend on inlining of any given function always
>happening.  It's already said, but perhaps not clearly enough --
>some of the verbage seems to suggest otherwise in a few places, and
>not everyone reads the entire description before jumping to
>conclusions.
>
>In summary, I haven't seen any clear description of the semantic
>lossage being complained about, and can only guess that the problem
>is that gcc has decided to stop inlining something it used to inline,
>which is not great, but not a semantic problem, just an optimization
>issue that bare-to-the-metal coders must deal with on an ongoing
>basis.  (To wit: if these functions hadn't *previously* been inlined
>due to their using &&foo, would the programmers have nevertheless
>used that feature, and given up the inlining, or given up &&foo?
>Either way, that's what they *can* do now, although ideally they
>shouldn't be made to choose.  And they can macro-ize their way out
>of relying on &&foo, if they like.)
>
>I do wonder if a "pointer to `here'" feature might be useful in
>place of what I gather is a kludge to get some kind of pointer
>useful for debugging, logging, and so on.  Perhaps `&& .' or
>`&& __label_here__' or similar could be reserved for that purpose,
>and be valid *only* as a `void *' that can be copied, printed, written
>to a file, etc., but not as the target of a `goto *x;' or any
>other pointer-like operation (++, +, -, ==, unary *, etc.).
>
>        tq vm, (burley)


>Date: Tue, 28 Jul 1998 20:00:13 -0700
>From: "David S. Miller" <davem@dm.cobaltmicro.com>
>To: burley@gnu.org
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
>        rth@cygnus.com, burley@gnu.org
>In-reply-to: <199807281536.LAA11100@melange.gnu.org> (message from Craig
>	Burley on Tue, 28 Jul 1998 11:36:27 -0400 (EDT))
>Subject: Re: inline functions and local labels
>References:  <199807281536.LAA11100@melange.gnu.org>
>
>   Date: Tue, 28 Jul 1998 11:36:27 -0400 (EDT)
>   From: Craig Burley <burley@gnu.org>
>
>   I'm confused -- what are the choices?  I've already tried to
>   construct an example showing the differences, and can't do so
>   without resorting to bogosities like having some external code
>   somehow depend upon the uniqueness, or value, of labels passed to
>   it as `void *' arguments.  (See below for an example.)
>
>Craig, I apologize, I should have posted the code which behaves
>differently if not inlined (due to kenners patch) so that the behavior
>issue in question is more clear.  There is a performance concern, but
>this is secondary compared to the loss in functionality change:
>
>extern __inline__ unsigned char *skb_put(struct sk_buff *skb, unsigned int len)
>{
>	unsigned char *tmp=skb->tail;
>	skb->tail+=len;
>	skb->len+=len;
>	if(skb->tail>skb->end)
>	{
>		__label__ here; 
>		skb_over_panic(skb, len, &&here); 
>here:		;
>	}
>	return tmp;
>}
>
>We use this for debugging, and the debugging information becomes
>useless if the procedure is not inlined.
>
>Later,
>David S. Miller
>davem@dm.cobaltmicro.com


>Date: Wed, 29 Jul 1998 12:33:49 -0400 (EDT)
>From: Craig Burley <burley@gnu.org>
>To: davem@dm.cobaltmicro.com
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
>        rth@cygnus.com
>Cc: burley@gnu.org
>In-reply-to: <199807290300.UAA05668@dm.cobaltmicro.com>
>	(davem@dm.cobaltmicro.com)
>Subject: Re: inline functions and local labels
>
>>Craig, I apologize, I should have posted the code which behaves
>>differently if not inlined (due to kenners patch) so that the behavior
>>issue in question is more clear.  There is a performance concern, but
>>this is secondary compared to the loss in functionality change:
>[...]
>>We use this for debugging, and the debugging information becomes
>>useless if the procedure is not inlined.
>
>Ah, I think I get it now.
>
>What you *want* is to "dump" the address of the caller's reference
>to the current function, so the ability to quickly localize the
>cause of the problem is improved somewhat.
>
>What you're *using* to get this is something different, which sometimes
>amounts to the same thing (e.g. when the code is inlined), but
>sometimes doesn't (e.g. when it isn't).
>
>A new notation added to gcc might be handy here (a notation that
>would basically be of roughly the same class as __PRETTY_FUNCTION__,
>though it'd involve lower-level code-gen issues than that).
>
>But it seems to me it'd be more worthwhile to consider implementing
>a general way to print a limited stack backtrace, which is an issue
>outside the language definition, and would require less cruft in
>your code overall.
>
>        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 07:20 PM 2/8/99 -0800, you wrote:
>  The way to use it is to put a function definition in a header file
>  with these keywords, and put another copy of the definition (lacking
>  @code{inline} and @code{extern}) in a library file.

*ahem* There are some of us with mail clients that don't know how to render
email with these formatting codes. (What is it anyways? It's not HTML or
RTF since my client will render those and it didn't render *those*... and I
know HTML anyways...)

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[craig]

>In article < 19990210133236.30212.qmail@deer >,  <craig@jcb-sc.com> wrote:
>>>On 9 Feb 1999 craig@jcb-sc.com wrote:
>>>
>>>> >Why don't you just remove "inline" completely, then?
>>>> 
>>>> Because it works just fine, and as documented, for 99.9999% of the
>>>> uses to which its put in code compiled by gcc?
>>>
>>>Right. So why break it then?
>>
>>By your apparent standards, it always *was* broken, because inlining
>>didn't always happen.
>
>No.
>
>gcc _did_ use to always inline if it at all could do so.

False.  gcc *never* inlined 100% reliably.  It might have tried,
and succeeded often enough, but other times, it just generated
bad code, or ran out of memory, or similar.

Exactly what would you do if one of those "reliable" gcc compilers
produced bad code when inlining?  Remember: you do not have the
option of answering "change my code to work around the bug", since
you are complaining about having to change your code to be correct
according to the gcc docs.  So what would you do, that you cannot
possibly cope with doing in the case you are now complaining about?

>There were
>cases that made it unable to inline, simply because the code itself was
>not conducive to inlining.  Those were _technical_ reasons for not
>chosing to inline something, and completely and utterly understandable. 

Yet, you completely and utterly do *not* understand some of the
common-sense reasons for gcc to choose *not* to inline something,
such as "the gcc developers decided generation of bad code was
too likely if a procedure meeting certain criteria was inlined"
and "the gcc developers decided it took too much memory to inline
this sort of procedure in certain circumstances".

Since "inline" is universally understood to be a *suggestion*, not
a *command*, it's not usually rigorously documented in terms of
exactly what conditions guarantee either 100% or 0% actual inlining,
especially not in the sense of a *specification* of the language
being compiled.

I'd be surprised if you could find a *single* compiler in the entire
market that documented *exactly* the criteria under which a procedure
would be guaranteed to be inlined, saying other procedures would
never be inlined.  If you do, please switch to using it instead of
gcc.  (It might be a Forth compiler, for example, so you'd have
to translate Linux into Forth.  You'd probably be happier with the
results.)

>For example, not inlining a recursive function is just obviously the
>right thing to do (yes, in theory you could try to make it iterative,
>but if the programmer gave the compiler a recursive function then it's
>the _programmer_ who is responsible for it, and nobody really expects
>the compiler to do miracles).

*You* do.  You expect the compiler to somehow *know*, all by itself,
with no human intervention, whether it is able to inline a procedure
from first principles and thus *always* produce correct code for any
case where it can be shown that inlining is at all possible.

Either that, or you expect the compiler *developers* to do miracles:
produce a compiler that can inline anything conceptually inlinable,
without ever producing bad code, running out of memory (when *not*
inlining *wouldn't* have), taking too much CPU time (compared to
*not* inlining), etc.

What is seems you're *really* saying, though, is that you prefer
the generation of bad code.  Though it's hard to tell *what*
you're saying, other than "I feel the need to spew at people who
are just trying to do a good job, because they disagree with me
about something regarding which I have little expertise".

For example, you seem to think taking the address of a procedure
makes that procedure uninlinable.  Wrong.  It just does *currently*.
It won't always do so.  I can easily imagine several ordinary,
common constructs that involve taking the address of a procedure
that a much smarter code-generation technology could happily take
into account when inlining.  Same for recursion.

Therefore, all anyone can truly say about "inline" is that it is a
*suggestion*, and guidelines about whether it actually happens are
just those -- guidelines, which can change from release to release,
perhaps even compile to compile.

If you don't want inlining to happen; don't say "inline"; use
whatever compiler options disable inlining; inspect the generated
code to see if inlining happened, and modify the source code
as necessary to avoid it, or modify the generated code and be done
with it.

If you *do* want inlining to happen, same as above, only inverted:
say "inline"; use whatever compiler options enable inlining; inspect
the generated code to see if inlining happened, and modify the
source code as necessary to force it to, or modify the generated
code and be done with it.

In both cases, once you achieve the desired results, throw them out
the next time you compile, regardless of whether you're using the
exact same compiler, source code, etc., but especially if you're
using a new version.

There.  I just stated what I bet *every* compiler vendor of the
industry would say, if pressed, about inlining and similar kinds
of optimizations.  Though gcc might be unique in simplifying some
of the above by offering `-Winline', I would *not* stake my life,
limbs, or property on the assumption that any failure to inline
would result in that warning, because a bug preventing the
warning is just too easy to put into gcc.

>>Yet, as I said, even then, it works just fine, and as documented,
>>for 99.9999% of the uses to which it is put in code compiled by gcc.
>
>No. It used to work for 100% of the caaes gcc could handle.

Again, a false, and useless, statement. Any of the cases gcc could not
handle either it did not inline, or it generated bad code.  I guess
you call generating bad code an example of inlinining being properly
"handled".

Essentially, you're making a case for generating bad code.  It's rather
disturbing to know that the author of the most visible free-software
product prefers bad code to be generated, when given a choice
between that and not inlining as "directed" by the programmer.

>The change broke that.

Your code was broken, AFAICT, and the change brought that to your
attention.  Please, deal with that and stop bugging us, though we
don't mind hearing about collateral changes resulting from bug-fixes,
especially when presented as such.

>It used to be a feature you could depend on.

It was always a feature you should *not* depend on, without using
`-Winline', providing external definitions to go with `extern inline',
or whatever was appropriate.

People who read the documentation *carefully* always understood that.

In that sense, you could and still *can* depend on "inline" working
properly.  That means you have to *use* it properly, which you
clearly haven't been doing.

You really ought to research the extensions you're using more carefully
before using them.  Perhaps you shouldn't be using them at all in a
product like Linux.

>The change broke that.

Again, no, it didn't.  You could always depend on "inline" to be
a *recommendation* that gcc try and inline the procedure, and
that if it couldn't or wouldn't, fine.  The results might or might
not be bad code; if bad code got produced, you could depend on the
gcc authors to try to quickly fix it, perhaps by disabling inlining
under certain circumstances until the underlying problem was fixed.

>Yes, the documentation had hedges to handle the real cases (like
>recursion etc) where inlining just isn't feasible, but the fact that it
>hedged its bets doesn't change the fact that people like me used to be
>able to rely on the compiler to do what it was asked to do.

That's correct.  However, the blame does not fall on gcc, or on gcc
developers.

Guess who's left.

The documentation did *not* say "any procedure meeting criteria X
*will* be inlined" and then expand on criteria X.  It *did* say
something much more like "procedures not meeting criteria X are
examples of those that won't be inlined".  That's a very different
thing.

Even if the documentation had been incorrect, relying so much on
the documentation for a product like gcc is, to put it simply,
rather unwise.  I don't trust documentation much, in general.
I've seen how it's put together.  And I know something about
the language(s) in which it is written, and their propensity for
making it easy for the author to write things readers can
misunderstand.

>If it was a case of "oh, gcc used to have a 50-50 policy on when to
>inline, and the change made that a 40-60 policy", then it would have
>been much more palatable. But it wasn't. It was a case of 100% success
>being turned into "I wonder what the hell they'll break next time
>around". 

In reality, it's a case of "I wonder how many more bugs like this
exist in Linux, which future changes in gcc might expose".

Your repeated claims that this constitutes "breakage" on *our* part
now constitutes an out-and-out lie, and I find it to be highly offensive,
since you've already been *thoroughly* corrected on this matter, yet
continue to state it.

The fact is: *your* code had the bug, not gcc, it was *your* code
that was broken, by relying on "inline" guaranteeing actual inlining.
Period.

That being said, yes, you *should* wonder what we'll break next time
around, given how much you depend on behavior not promised in iron-
clad terms in the documentation, and on the interaction of lots of
extensions, some of which are some combination of poorly documented,
poorly designed, poorly implemented, and rarely tested, even in
isolation.

>Repeatability is good.  Random changes that break existing behaviour for
>no technical reason is bad. 

I agree, but nothing was broken by this change that I've been able to
discern, based on the posts I've read.

In fact, it appears something was fixed.

There was a clear *technical* reason for the change, from what I
understand, and nothing particularly random about it.

That there apparently were collateral *changes* -- not *breakages* --
to generated code due to the fixes is unfortunate, and generally we
try to minimize that sort of thing, as a much-lower-priority thing
to worry about than, say, generating correct code or maintaining
some reasonable degree of performance vs. previous releases
(rougly speaking).

But, those kinds of collateral changes do *not* necessarily constitute
a bug in the end-user sense of the term, not even in the ordinary
sense of the term.  Sometimes, things just change.  Sometimes, these
changes expose previously hidden, broken code elsewhere, as appears
to be the case here.

>>(That's not surprising, since gcc is, generally, based on standards
>>such as ISO C, which presumably make it much clearer that "inline"
>>is, like "register", a mere hint.)
>
>"extern inline" is a documented gcc extension. It may be covered by ISO
>C these days, but it didn't use to be.

My old copy of ANSI C (draft) doesn't even cover `inline'.  So, the
*only* source of information on it was the gcc docs, as it turns out,
unless you want to include drafts of subsequent standards or
something (*none* of which promised the behavior on which you're
depending, I'd guess).

Good engineering means not constructing a large-scale project to
depend on features specific to only one incarnation of a standard,
including its extensions, especially poorly-documented ones.

You'd be smart to stop using gcc-specific extensions in general,
at least to stop using them in so many dizzying combinations.
By "smart" I mean you'd be a better engineer.

If you don't care to be a better engineer, you shouldn't be surprised
when things that used to work fine stop working.  (And if you do
become a true engineer, you'll learn to *expect* that ;-).  Engineering
is, among other things, the science of designing things so they work,
period, AFAIK.  I don't think gcc is very well-engineered in that sense;
it's clear Linux isn't, based on your posts, because innocuous
changes to gcc can, apparently, break it (else you're making a huge
fuss over nothing).  At least the gcc developers seem to agree on
making it, on the whole, better engineered -- they generally know
better than to design it assuming undocumented behavior in underlying
products never changes.

You seem to think everything is black-or-white: do what the programmer
said to do, even if it means generating incorrect code, and, oh
by the way, never generate incorrect code.

Reality is different.  Good engineering means having to come to terms
with reality.

>"address of a label" is a documented gcc extension, and is NOT covered
>by any C standard (pending or accepted) that I know of.

So why are you using it?  Why would you design a product to so
completely depend on the correct interaction of a variety of
extensions supported by only one compiler out of so many choices
on the market?

How many *other* products do you know out there that depend to
a similar degree on the correct interaction of so many gcc
extensions?  Are *their* authors so sensitive to changes in
code generation?  If the answer is "none", then why are you
making *your* code *more* unreliable than the rest of the
industry by so depending?  Is being on the "cutting edge"
that important?  If so, why not *act* like someone who *understands*
what being on the cutting edge *means*?

("Hey, I've driven around this 25mph-posted turn at 80mph for
years now and never skidded out.  *Now* you tell me this stuff
called `black ice' made me skid out and smash up my hugely
expensive car.  It was *your* fault for not making this clear,
you should reimburse me for my car, and make sure this `black ice'
stuff never, ever happens again!")

>As such, the people who brought up "standards" as an argument for
>changing the behaviour are fairly hypocritical: it's a good argument but
>in order to hold water it has to be _relevant_.

I don't know that it isn't relevant or that they're being hypocritical:
my impression is, "inline" *is* covered by drafts of upcoming standards
of some relevance.  But if you didn't read a product document, or even
a standards document, guaranteeing actual inlining in the presence of
"inline" in iron-clad, unambiguous terms, *you* were at fault for
depending on such actual inlining.

The reality is, you're trying to exploit nearly every detail of how a
particular compiler works without understanding what a compiler is, what
it does, how it evolves vis-a-vis the development process, language and
library standardization, and so on.

Please stop doing that.  Stop using compilers, or at least stop using any
extensions they offer and stop relying on any *particular* behavior they
exhibit.  Or, *learn* what compilers are all about, if you have the
10 years or so to spend doing it.

You've gotten *tons* of good, solid advice about the issues involved
from people with far more pertinent expertise than you have developing
operating systems, and have so far done a damn fine job of ignoring it.

If you think the "fixes" to the recent "objectionable" patch will
solve your problems, they won't -- because the underlying problems
are *yours* and thus Linux's, not gcc's.  The problem, or some
problem just like it, *will* occur in the future, and our response
will be basically the same: sincere attempt to minimize collateral
changes while striving, *first and foremost*, to prevent the generation
of bad code.  You Have Been Warned.  Yet Again.

Given that we've gone through this with you in the past (and not
just in the area of compilers, IIRC), I suggest you wean Linux
from depending on gcc at all.  Make it compilable by any ANSI C
compiler, for example.  Then maybe you won't get so upset every
time a fairly trivial change to gcc's code generation occurs, and/or
we won't have to endure your flames.

That would be a heck of a lot more progressive than just deciding to
stick with gcc-2.7.2.1 forever.  But if you want to go that route, it
isn't necessarily a bad decision either, as it'll amount to "nailing
down" the behavior of one crucial component in a much larger, complicated
system (Linux), meaning the developers of the larger system can learn
how to avoid the problems in the nailed-down gcc, which they'll
learn more and more about as time goes on.  (There are disadvantages
to that approach, of course.  You'd be changing your code to work
around known bugs in 2.7.2.1 rather than changing it to better
accommodate ongoing improvements in compiler technology, for example.
In the long run, Linux would end up either coded entirely in `asm'
directives, or running slower than other operating systems that
had fewer lines of code and, probably, more features.)

The decision is yours.  Our viewpoints on this matter will not change,
because they cannot -- if we made you the promises you seem to want,
we'd be lying, in which case we might as well go into politics so
we can get babes and power.  That'd just leave gcc development open
to others who aren't suited for that kind of thing, i.e. the current
situation.  So the only reasonable possibility is for *you* to adapt.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Alan Cox]

> "correct" way to do it. (Famous last words, I know. On the other hand,
> neither 'side' of this debate needs the ego boost provided by Having Been
> Right All Along, so...)

Well its really a 2.3 issue in my book. We tied 2.0 to a compiler and its
proved the right choice. Playing games with sensitive inline code during 2.2
doesnt appeal to me at all

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Joe Buck wrote:
> 
> Hmm.  Linus does seem to have a point here.  See the node "Inline"
> in the gcc manual.

Thank you. Exactly.

This is not about "what would we do if we redesigned the language". This
is about existing users that have used behaviour and documentation that
has been stable for at least the 8 years I've used gcc, and are extremely
irritated at some willy-nilly changes that break existing documented usage
for no apparent technical reason.

		Linus

Re: kernel-2.2.1-undefined references.

[Matthias Urlichs]

Hi,

Paul Derbyshire:
> >  @code{inline} and @code{extern}) in a library file.
> 
> *ahem* There are some of us with mail clients that don't know how to render
> email with these formatting codes. (What is it anyways?

Texinfo. I've suffered from the same disease myself; after writing on a
largish .pod file all day, the habit to B<boldface> and I<italicize> and
C<code>ize carries over to email.  :-/

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
Anything not worth doing is not worth doing well.
                                       -- G. Bell

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 12 Feb 1999 craig@jcb-sc.com wrote:
> 
> P.S. Yes, folks, I realize that Linus almost certainly won't bother
> actually reading the below

I actually do real the email I get. I just don't have time to answer all
of it. I've answered most of the relevant postings (but not all of the
contents) in this thread because I feel strongly that there _is_ a real
need to have what I call a "working inline" while you obviously don't
think so.

The emails you quote are from the previous time this happened. As now,
nobody actually suggested a good working way to do what we wanted to do
without just completely resorting to macros (and I've already explained
why I dislike macros). 

What you suggested then isn't any better than what you're suggesting now: 
implementing new features in gcc doesn't obviate the need to be able to do
the same thing with old code. And implementing a back-trace by hand is
architecture- and compiler-dependent, which is silly because when that
breaks due to compiler changes you'd just complain that we should do
something else. You can't have it both ways, Craig. 

Face it: what Linux does is entirely reasonable, trying to get a backtrace
in a architecture-independent way. Yes, it bit us, but it was certainly
not an unreasonable thing to do.

Do you really think it's unreasonable to ask for some way of forcing
inlining, when the compiler obviously can do it? It doesn't have to be
"extern inline", if you're afraid of polluting a future standard
namespace. 

		Linus

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 12 Feb 1999 craig@jcb-sc.com wrote:
> 
> >To _me_, "standard C" has not been important at all. I'm _more_ than happy
> >to use gcc extensions, because I think they are worthwhile in the kernel. 
> 
> That means, like I already said, you have to be prepared for a very
> bumpy ride.  You've shown that you have trouble coping with that.

Umm..

I had no problems with gcc features for about six or seven years of Linux
development. These things simply didn't use to happen: despite upgrading
_major_ versions of gcc (when Linux started we were using gcc-1.40), for
those six-seven years there weren't really any changes that I ever had
problems with. 

There were tons of code generation bugs over time, but hey, I _expect_
bugs, and while compiler bugs are sometimes really hard and nasty to find,
I don't complain too much: I report them, and I tell people not to use
certain versions. I may be grumpy for a while because I spent ages looking
at a bug that didn't turn out to be mine, but I never get the feeling that
I should really dislike the compiler people. 

The reason I have been complaining so much lately is that I think that the
egcs development has lost that stability. Again, never mind code
generation bugs, I'm talking about _interface_ stability. I've had much
more problems in the last year than I had in the seven years preceding
this.

This may actually not be due to technical reasons as much as simply due to
a different open development model - it may just be that more people see
"partial" work, and some of that partial work breaks stuff. Fine - I like
open development myself, and I use it. But when somebody complains to _me_
that I broke old interfaces, I consider that a bug unless I have a very
very strong technical reason to tell people that I simply _cannot_ support
some old interface any more. 

In contrast, on this list, when people complain that egcs breaks existing
code, the answer is "shut up and live with it" - and then they Cc: me on
the damn thing. And that's why I get so upset, and why these flame-wars
erupt. 

"Shut up and live with it" is not a way of caring for your customers. And
creating the best compiler in the world is not just about code generation:
it's about supporting the people that use it, too. 

I could change my kernel interfaces and tell people that "shut up,
recompile, and be happy". Trust me, that doesn't work when you have a
serious project that you expect others to be serious about too. I make
_damned_ sure that I don't break binaries, and when I do it by mistake I
have egg on my face and I fess up to screwing up. 

On this list, nobody 'fesses up to screwing up any more. And that's sad. 
It makes the egcs project look less serious, and more like a bunch of
people that just want to play at making a commercial-grade compiler. 

		Linus

Re: kernel-2.2.1-undefined references

[Mark M. Kettenis]

   Joe Buck (jbuck@Synopsys.COM) wrote:

   It might be appropriate to generate an error, not a warning, if
   "extern inline" fails to inline, since it is clear from the documentation
   that this is not a mere hint.

I may be quoting you out of context, but if you really are suggesting
that failing to inline an ``extern inline'' function should generate
an error (or even a warning without explicitely asking about warnings)
please think again.

The gcc documentation contains the following paragraph:

      This combination of `inline' and `extern' has almost the effect of a
   macro.  The way to use it is to put a function definition in a header
   file with these keywords, and put another copy of the definition
   (lacking `inline' and `extern') in a library file.  The definition in
   the header file will cause most calls to the function to be inlined.
   If any uses of the function remain, they will refer to the single copy
   in the library.

This is exactly how we use ``extern inline'' in the GNU C Library and
the Hurd.  Since even some of the standard ANSI C headers contain
``extern inline'' function (of course properly marked as extensions
and only if gcc/egcs is used) generating errors could possibly make
compiling almost any program impossible, and generating warnings would
be pretty annoying.

The documentation on ``extern inline'' may not be entirely clear, but
the above paragraph is crystal clear.  ``extern inline'' is a hint,
and not providing an additional definition without `inline' and
`extern', is asking for trouble.

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> Date: Mon, 8 Feb 1999 18:42:53 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>

> Removing features without giving a reasonable way of doing the thing
> that gcc has successfully been doing for 8 years is not reasonable.

Actually, my guess is that someone reported a bug, and someone
investigated it and found that two orthoganal features that seem like
they should work together just fine, in fact didn't and that codegen
correctness was comprimised by the combination and that because of
this, the combination was disabled because the bug fixer didn't have
time to extend the implementation to handle the combination.  I have
done this myself with complex cases of exception regions and inlining.

I hate to even respond to this, because I don't know for certain this
is the exact case at hand.  I hope someone with the knowledge can
confirm it.

Now, I hate that you got hit by a bug fix like this, but if this is
the case, I think it is better to break your code than have the
compiler generate wrong code, even though it may have been doing it
for 8 years.

> Codifying the fact that if you really _rely_ on inlines

I am sorry, don't do that.  :-(

> You also seem to prefer breaking documented behaviour.

To me, the phrases `Note that certain usages in a function definition
can make it unsuitable for inline substitution.'  and `Inlining of
functions is an optimization and it really ``works'' only in
optimizing compilation.' and `Some calls cannot be integrated for
various reasons' I think clearly set the users expectation
appropriately.  If you can suggest wording that would have been
clearer to you, we can fix the document.

Re: kernel-2.2.1-undefined references.

[craig]

>I will provide a link back to this message when it happens later.

I wonder if my email, <199807281536.LAA11100@melange.gnu.org>, is
available on-line anywhere.  It was sent to the egcs-patches and
gcc2 mailing lists back last July.  Looking at it, I realize it's
likely I confused <davem@dm.cobaltmicro.com> with Linus in my
recent posts, that is, thinking it was Linus, not Dave, who was
trying to figure out the `extern inline' stuff.  But I'm not sure
why the info provided at great length to someone, seemingly a
Linux person coordinating with egcs/gcc, didn't actually get back
to Linus before this issue came up yet again.

Looking at the thread, it looks like all that <davem> wanted was
some assurance that this "bug" would someday be fixed, and as long
as he got that, there was no need to bother with all the other
stuff some of us (especially myself) were saying, which has recently
been described as "superfluous" (though it turns out to have been
prophetic, if I understand the sequence of events correctly).

Anyway, it's kind of sad nobody (including me) took serious action,
and that Linus didn't somehow get the info, based on that email
of mine back then, and that I didn't first look it up and simply
re-post it, in its entirety, before going to all the trouble of
explaining things...again....

And, as with this time, I wasn't the only one explaining the reality
of compiler development.  No less than Richard Kenner and Richard
Henderson did some of the explaining back then as well.

So maybe we *will* all go through this again, but hopefully with
pointers to these old messages instead.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> Date: Mon, 8 Feb 1999 12:15:40 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>

> I'm not trying to be unreasonable. I'm just saying that if there is
> a function that is marked inline that can be inlined, it _should_ be
> inlined, because the compiler _never_ knows better than the
> programmer.

Let me provide a counterpoint.  In C++, it is common to have
templates.  In templates, it is common to have lots of small,
sometimes, really small functions.  Sometimes, programmers put
`inline' on them.  The C++ standard says they `inline' by default on
those defined in the class body, this also is common.

Now, if you put all of that into a complex piece of software, you wind
up with cases where, the compiler wants to consume 10 terabytes of
swap space trying to fulfill the users desire to inline.  Yes, I am
not marking this up, it happens (see a user bug report from use a few
months ago for this exact case).  We have a choice, require they
change their source code (not an opnion, it looks quite nice already),
require they buy 10 terabytes of swap (only $216k, so why not?), don't
compile their code and tell them to go out and buy a better compiler,
or stop inlining just for C++ (I don't like random divergence), or
require they not put inline on things or define them in the class body
or violate the users expectations set from the standard for C++.

Which do you prefer?

I prefer to follow the standard where it says that inline is a hint,
and only a hint.  I have submitted patches to artificially limit the
size of functions that can be inlines to some random size that was
meant to be big enough, so that it would be faster in the typical case
(due to caching effects), than if there were no limit, and so that the
code would even compile.  The limit was something like 6400
instructions.  I tried to pick it so that if everything fit in the
cache, performance would still be within 1% or so of perfect.

Re: kernel-2.2.1-undefined references.

[craig]

>Jeffrey A Law <law@hurl.cygnus.com> writes:
>
>> No.  ANy code which depends on a function being inlined for
>> correctness is broken.  That's it, there's no if and's or but's
>> about it.  The linux kernel depends on certain functions being
>> inlined and is therefore broken.
>
>In a strictly literal sense, I think you're right.  Perhaps this is
>better reported as a documentation bug rather than a compiler one.

It already was, long ago, and again more recently.  And the compiler
buglet(s) were fixed, though more might well occur, as well as non-bugs
that have the same effect as these buglets -- namely, stopping the
compiler from actually inlining some "extern inline" functions.

>I think it's unfair on Linus to criticize him, however.  He's made a
>reasonable interpretation of what the documentation says (it's how I
>read it, too) and this interpretation holds for more than one version
>of the compiler.

Please read my emails, from around six months ago, quoted in another
message, and the emails earlier in this thread, and ask yourself:

  "How many times have the Linux developers, and Linus in particular,
   been told that the documentation does *not* mean to promise that
   `extern inline' functions will be predictably inlined by any and
   all future versions of the compiler?"

What keeps happening, instead, is that, every time they are told
"you cannot count on `extern inline' always inlining", they ask
"then why not get rid of that construct?" or similar.  And they
never seem to learn from the answers they're given.

>His interpretation also strikes me as describing a useful feature: a
>macro dressed up as a function.  Of course there'll be examples of
>functions which wouldn't be inlineable, but surely when what I've got
>is basically a macro, it would be handy to be able to use function
>notation (in order to get argument copying, type checking, and so on)
>and to know that the thing will be treated as described in the
>documentation (but with the offending "most" replaced with "just about
>all"---with the exceptions being indirect calls and the like, I
>guess)?

Let me explain something.  I'll write this very slowly, so everyone
can keep up.  :)

The GNU C language is not a stand-alone, GNU-only language that happens
to be called "C".

The GNU C language is a set of extensions (some of which are some
combination of poorly thought-out, poorly specified, poorly designed,
poorly implemented, and poorly documented -- which is typical of
most vendor compilers for languages like C and Fortran, in my
experience) grafted onto an approximation (a pretty close one) of
a *standard* (or two or three) for the C language -- K&R C, ANSI C,
ISO C, and upcoming versions.

All of the *standards* upon which the GNU C language is based share
the following trait:

  The implementation (compiler, linker, libraries) may transform
  the program in any form, as long as the resulting behavior is
  "as if" the specified behavior occurred.

This (my approximate wording, but you get the idea) is known as the
"as if" rule.

For example, gcc, and any *other* C compiler, may transform the
relatively simple line of code, `a = b + c;', into a complex multiply,
as long as it acts "as if" it simply added `b' to `c' and stored the
result in `a'.  It could even execute the statement by writing `b' and
`c' to a file in /tmp, invoking `bc' to add the values and write
the result in `a', then read that back...etc.

It also means that, unless the specification for a vendors' compiler
*specifically* and *explicitly* suspends the "as if" rule for a
feature or extension, the compiler is free to choose any implementation,
as long as the resulting behavior is "as if" the direct description
was obeyed.

Since "inline" does not connote *any* specific semantic change in
the behavior of a program, it can *never* be assumed to make any
specific change in the *implementation* of that program (as produced
by the compiler, etc.).  That, simply put, is *not* the purpose of
"inline".

gcc offers, typically, extra-linguistic methods to sample, or perhaps
override, behaviors beyond the bright line of the "as if" rule.
For example, `-Winline' is claimed to do this: if inlining doesn't
actually happen, you get a warning.  (That's an example of what I
mean by "sample", since the warning can be safely ignored.)

But, the *linguistic* methods to sample or override these behaviors
are generally inappropriate in a language like C.  There are too many
combinations of too many things people would like to ensure, as far
as particular implementations, above and beyond what the specification
normally assures: precision of intermediate floating-point calculations;
precision of those intermediates if they get spilled; whether they can
get spilled; how overflows of integer computations are to be handled;
just to name a very few, involving some issues recently discussed here.

Each little audience will want its own particular "gimme", an
implementation-related bolt-on here, another kludge there.

If you want gcc to be almost completely unmaintainable within five
years, agree to provide just the proposed extensions that "make sense",
"seem useful", and "seem easy enough to implement" or for which "we
already have a patch".

An analogy I like to use is what the mathematician says in the movie
"Jurassic Park", something along the lines of "just because you
realized you *could* doesn't mean you *should*": just because we
*can* extend the language, implement the extension, and promote it
hither and yon via the power of open-source software and the Internet,
doesn't mean we *should*.

But, I know firsthand how easy it is to get caught up with our
new-found power to "move mountains" by tinkering with language
and interface designs, assuming we were given this power because
we were meant to actually wield it, day in and day out, as per
our whims, well-intentioned or otherwise.

>I confess I don't understand why there might be cases where functions
>*must* be inlined for correctness, but performance matters too:

C is not a language that provides an expression of desired performance.

Therefore, users of its compilers must themselves take responsibility
for the performance of their code.  Many of them do this by picking
a compiler vendor once, but the most demanding (or, demanded-upon) of
them figure out ways to verify that the desired performance levels are
achieved, for *each* compilation invocation, often by some combination
of tactics, including carefully studying the code output by the
compiler.

If a gcc user is depending on a particular performance level or
memory footprint from gcc, and isn't taking *independent* steps
to verify these are met, they're making a huge mistake, because
C is not a language designed to eliminate the need for humans to
engage in that sort of activity.

The best thing gcc can do to help *everyone* is to be, generally,
fairly predictable when it comes to making implementation decisions
that aren't clearly wrong.

And *that* is what Linus has been asking for all along, and what I've
seen, I think, all the pertinent gcc developers agreeing to, even
while they're saying "but don't *depend* too much on this".

The problem is, he and many others don't, or someday won't, agree
on what constitutes "clearly wrong".  Always inlining "extern inline"
in a way that disregards increased Icache usage is "clearly wrong",
though, when the compiler understands Icache usage -- which gcc
currently does not, but someday must, to remain competitive.  But
if it's "clearly wrong" to not inline an "extern inline" procedure
*today*, as people like Linus argue (mainly because they happen to
depend on another extension behaving in a manner not exactly specified,
meaning they're disregarding the "as if" rule), that means it'll either
still be "clearly wrong" then, or a promise, if it had been made, will
have been broken.

Either way, somebody suffers: the people who count on the compiler
to produce the most optimal code it knows how to produce at any
given time, or the people who count on the compiler to behave as much
as it used to behave as it possibly can.

So it is up to the gcc *developers* to specify, as clearly and simply,
what the language constructs and extensions do and do not guarantee,
along with guidelines regarding how they're currently implemented.

Doing that is a *lot* of work, and it has yet to be done.  For it
to be done, some people with *significant* expertise in the relevant
fields (technical writing, code generation, artificial-language
design, product development, user-interface design) would have to
expend a moderately significant effort.

Then, they'd have to *maintain* the documentation, all the while
helping the gcc (code) developers stick to the documented
interfaces and guidelined behaviors, and alert the writers to when
guidelined behaviors were going to change, so the docs could
be adjusted.

I don't see how that kind of effort will be seriously undertaken
as long as so many people insist on disputing what the documentation
says, disregarding the advice they're given as to how much to rely
on the documentation for assumptions about code generation, proposing
new extensions be added, and demanding old extensions be supported
exactly as they've always happened to work in the past.

In other words, to get where most gcc users probably want, ideally,
gcc to be, they should to encourage the gcc product to be "leaner
and meaner", so it can be more clearly specified, and documented,
over time.

Instead, what most everyone does is make suggestions that usually
*increase*, rather than *decrease*, the burden on the gcc development
team, when what is actually needed is to encourage the gcc product
to be "leaner and meaner", so it can be more clearly specified, and
documented, over time.

People who don't understand the above inevitably say "well, anyway,
I just want my feature, it isn't so hard to do, right?", and accuse
people like me, who actually understand the issues and how to meet
the challenge, of being in "ivory towers".  (I seriously doubt
the tower I'm in is "ivory", but it sure does give me a much wider
view of what's going on out there than I'd have if I just took the
day-to-day, let's-go-with-the-flow-and-implement-whatever-seems-popular,
approach.)

In the end, if the gcc user community can't tolerate keeping the
product lean and mean, they'll have to tolerate it being less well
documented and/or more buggy than otherwise.

>functions are more readable than longish macros with silly temporary
>variable names and things---people (for whom portability between
>compilers isn't critical) ought to be encouraged to use more readable
>mechanisms where possible, and providing suitable mechanisms is surely
>a Good Thing.

That's *certainly* true, and I heartily applaud that.

It is *incredibly* challenging to design a language that allows
programmers to specify just what they want to have happen *and*
also allow them to specify exactly how the compiler is to make
some unspecified thing happen.

I call the former SWYM -- "Say What You Mean" -- defined as a
specification from which not one single expression, operator,
variable, whatever, can be removed without making the specification
inviable.  I call the latter DWIS -- "Do What I Say" -- defined as
a specification of how resources are to be employed, step by step,
with as little information on what is actually the desired output
as possible.

(These definitions can pertain to layers of translation.  The
SWYM-like definition of a Fibonacci sequence is, in its ideal
form, not an imperative one -- it does not define the order
in which the numbers are generated, just the order in which
they occur correlated to the sequence of natural numbers.
A direct DWIS-like translation of that sequence can, in turn,
be viewed as a somewhat SWYM-like imperative program, which a
compiler is free to implement however it likes -- which is,
in turn, a DWIS-like translation that, to a CPU, is more
SWYM-like in that the actual ordering of operations isn't
necessarily obeyed as written, as long as the results occur
"as if" they were.)

So, the debate I see here, and often in other language/compiler
forums, boils down to this:

  Is this language destined to be more SWYM-like, or DWIS-like?

GNU C, and C in general, are on (perhaps stumbling along) a path
towards more SWYM-like behavior.

GNU C still tries to provide some DWIS-like features, but at
some point, it will be nearly impossible to maintain it without
making a choice between SWYM or DWIS.  And more and more DWIS-
like features get added to it all the time, unless people (like
myself) spend lots of time arguing against them, assuming we're
even successful.

That implies that every DWIS feature added makes it that much harder
to improve the SWYM characteristics of a language like C and/or
a compiler that supports it.

In fact, every *discussion* of a potential new feature, especially
a DWIS-like feature (which accounts for most of such discussions),
wastes time that could go to improving gcc in much more tangible
ways, assuming I'm correct in my estimate that the industry, as
a whole, wants more SWYM-like behavior from products like gcc.

>And, I imagine, in a kernel sometimes performance can
>affect correctness (though I may be quite wrong---I've lost the
>mention of which functions in the kernel were hit by this, and the
>"extern inline"s I can spot look like they shouldn't be critical).

Performance of a kernel, or a real-time process, is *crucial* to
correctness.  Same for other disciplines.

The short answer is, for those disciplines, C isn't *close* to
SWYM, and the programmers in those disciplines therefore tend to
program in a more DWIS-like fashion, and ask for more DWIS-like
features.

But, it is almost impossible for me to imagine enough DWIS-like
features being added to C (say, GNU C) to actually achieve what
they want: guaranteed meeting of performance criteria without
having to study the generated assembly code and/or do other kinds
of performance measurements.

Encouraging them to go down that path, by offering to add the
DWIS-like features they want (e.g. the "__force_inline" keyword
I proposed six months ago), leads them to a technological
cul-de-sac, and also leads to a compiler that just isn't likely
to make the huge numbers of SWYM-like-C users happy.

(An aside: what many Fortran vendors did, when Fortran 90 came
out, was simply offer Fortran 90 compilers that did not support
most of the extensions their still-current FORTRAN 77 compilers
supported.  That basically forced their users to choose between
the DWIS-like extensions they'd become accustomed to, in a product
line they could see would soon stop being developed, and the
SWYM-like features Fortran 90 offered as replacements for most
of the old extensions.  I'm not sure whether any Fortran 90
implementations exist that also handle all the old FORTRAN 77
extensions that are popular, but given what I know about the
effort needed to do that, I very much doubt a GNU Fortran 90
compiler will ever exist that does that.  Too Much Baggage.
Yet g77 users likely to fund a g90/g95 will tend to insist on a
"smooth upgrade path", meaning they won't want to have to drop
their use of extensions wholesale as they move up to a g90/g95.
So they'll have to fund a project several times as expensive
as otherwise necessary, which they're unlikely to do.)

And, in case you're wondering, yes, I've been thinking about
what a complete SWYM+DWIS development environment would look like,
from the ground up.  For over twenty years now.  Because I want to
be able to seamlessly move from programming in raw machine code all
the way up through full functional programming (*including* timing
requirements, still with no reliance on side-effect-based programming),
without having to jump in and out of the development environment and
its built-in programming language (with, perhaps, distinct dialects).

It's *incredibly* hard to do this right, and it, in my estimation,
puts a ton of new requirements on lots of areas that we currently
take for granted, like searching, editing, patching, documenting,
testing, and so on -- so *those* areas, seemingly, have to also
be included in the overall effort to redesign the system according
to SWYM+DWIS principles.

(Maybe this year I'll finally start to do something tangible towards
realizing this long-held dream, to see what I've got in my head,
and whether it makes any sense.)

In the meantime, it'd be a good idea to decide which direction
gcc should go, which I think the industry as a whole has concluded is
"SWYM", since that's where C's going, and stick with it, completely,
or nearly, ignoring proposed extensions representing the other side,
because C, as a language, cannot support both paradigms (it can
barely support one).

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> From: craig@jcb-sc.com
> Date: 12 Feb 1999 03:11:18 -0000

> If that's right, this problem will occur again, sooner or later.

Yes, and I can tell you when too.  When the kernel doesn't fit on a
floppy, and they exhaust all compressive techniques, and someone
discovers -Os makes the kernel run faster and that it is smaller,
someone will discover those routines that were inline, are not
anymore.

:-(

Then we can hear the bug reports again and explain that even when you
ask the compiler to inline, with -Os, _sometimes_ the compiler
doesn't.

I will provide a link back to this message when it happens later.

Re: kernel-2.2.1-undefined references.

[craig]

>and on the whole we'd like to try triggering that sort of thing,

I meant "try *to avoid* triggering", which I hope was obvious.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 03:24 PM 2/13/99 -0000, you wrote:
>Do you have any bounced email to forward along, so I can see what
>was actually happening?  That's the first thing my ISP would
>ask for, probably.

Yeah. Here. (Apologies to list, but since Craig's mail server is still
bouncing mail intermittently...)

I already tried sending this to postmaster@jcb-sc.com, and got the same
sort of bounce. I did Whois lookup and saw their technical and admin
contacts at world.std.com; I mailed them suggesting they fire the
postmaster and noc at jcb-sc.com and telling them why, and world.std.com
bounced as well. Is damned weird.

At least if you suddenly find that your subscription to egcs lists has
evaporated, you'll know why (your server started bouncing incoming mail
again and triggered the automatic bad-address-unsubscribe) and who to blame
(your ISP).


>The original message was received at Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>from dialin109.ottawa.globalserve.net [207.176.153.109]
>
>   ----- The following addresses had permanent fatal errors -----
><craig@jcb-sc.com>
>
>   ----- Transcript of session follows -----
>... while talking to world.std.com.:
>>>> MAIL From:<pderbysh@usa.net>
><<< 550 Wrong.
>554 <craig@jcb-sc.com>... Service unavailable
>Reporting-MTA: dns; smtp2.globalserve.net
>Received-From-MTA: DNS; dialin109.ottawa.globalserve.net
>Arrival-Date: Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>
>Final-Recipient: RFC822; craig@jcb-sc.com
>Action: failed
>Status: 5.0.0
>Remote-MTA: DNS; world.std.com
>Diagnostic-Code: SMTP; 550 Wrong.
>Last-Attempt-Date: Fri, 12 Feb 1999 19:02:40 -0500 (EST)
>Return-Path: <pderbysh@usa.net>
>Received: from chaoszone (dialin109.ottawa.globalserve.net [207.176.153.109])
>	by smtp2.globalserve.net (8.9.1/8.9.1) with SMTP id TAA19254;
>	Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>Message-Id: < 3.0.6.32.19990212190141.00891c70@pop.netaddress.com >
>X-Sender: pderbysh@pop.netaddress.com
>X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
>Date: Fri, 12 Feb 1999 19:01:41 -0500
>To: craig@jcb-sc.com
>From: Paul Derbyshire <pderbysh@usa.net>
>Subject: Enough is enough... truce time. Re: kernel blah blah blah
>Cc: egcs@egcs.cygnus.com
>In-Reply-To: < 19990212221225.22651.qmail@deer >
>References: < 7a203j$9cf$1@palladium.transmeta.com >
> < Pine.LNX.3.95.990209135218.2116D-100000@penguin.transmeta.com >
> < 19990211201836.2781.qmail@deer >
> < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
> < 19990212031118.4271.qmail@deer >
> < 7a203j$9cf$1@palladium.transmeta.com >
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>
>Ohh....my...GOD.
>
>*referee whistle blowing sound*
>
>HEY. Lets have a truce here... no more mudslinging and general aggravated
>shouting. I'd think that's beneath the station of the likes of Linus
>Torvalds and the GCC/EGCS development gurus.
>
>In "A Final Solution." I suggested some ways to change the compiler or
>Linux or both to meet everyone's needs and leave everyone happy.
>
>As for who's wrong, I don't think anyone is. There has been a
>*misunderstanding* about the ambiguous phrase "like a macro" in the
>documentation. Some took this fairly literally regarding faithfulness of it
>being expanded inline; others took it to mean "like a macro when it is
>inlinable". Chalk it up to ambiguous documentation, and let's bury the
>hatchet. And to reiterate, there are 3 things that can be done.
>
>1. Make the dox clearer about "extern inline".
>2. Linus, if worse comes to worst, you may just have to replace one-
>   off inlines with macros, or at least use -Winline and jiggle it
>   until it inlines. This strikes me as rather unsatisfactory
>   however.
>3. EGCS developers, if "extern inline" can't be and wasn't meant to
>   be what Linus had in mind after reading the dox for it, I suggest
>   adding an __attribute__ ((always)) that causes an error if the
>   function is not inlinable or a label address from a label inside
>   the function is used outside it and an __attribute__ ((once)) that
>   inlines a function where it's used, making an error if it's used
>   more than once; this means that the compiler can inline the
>   functions with these attributes without any worry that it will
>   lead to ambiguous references to addressed labels.
>
>-- 
>   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
>-()  <  circles, and bark is not smooth, nor does lightning travel in a
>   `*'  straight line."    -------------------------------------------------
>        -- B. Mandelbrot  | http://surf.to/pgd.net
>_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
>Programmer & Humanist|ICQ: 10423848|
>


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 11 Feb 1999 craig@jcb-sc.com wrote:
> 
> >"address of a label" is a documented gcc extension, and is NOT covered
> >by any C standard (pending or accepted) that I know of.
> 
> So why are you using it?  Why would you design a product to so
> completely depend on the correct interaction of a variety of
> extensions supported by only one compiler out of so many choices
> on the market?

Are you being stupid or argumentative? 

To _me_, "standard C" has not been important at all. I'm _more_ than happy
to use gcc extensions, because I think they are worthwhile in the kernel. 

So "address of label" is a documented feature of the only compiler I
compile the kernel with.  As is "inline". And my argument was that
_neither_ of those features were mentioned in any C standard ("inline" has
since been added to the proposed standards) - but they were very much
mentioned in the gcc documentation.

Ergo, ANYBODY who uses "standard conformance" as a reason for supporting
their argument just needs to think twice. That was my only argument. I'm
just trying to show people how silly it is to say that "oh, the standard
says that 'inline' is just a hint", when the current C standard says
nothing of the sort at ALL.

[ rest of your silly email removed - you seem to be arguing against using 
  gcc in the first place. I just want to make sure that gcc continues to
  be usable and good for Linux ]

		Linus

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 11:15 PM 2/11/99 -0000, you wrote:
>Obviously the combination of these extensions worked sometimes.
>Is there any way to find out when it works and when it doesn't?
>It should be a deterministic problem, no?

So is the halting problem <g>

[deletia]

Well said. Let's all get along.
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Joe Buck]

[ __builtin_constant_p ]

> It works in development versions of egcs, but as far as I know of it does
> not work in _any_ released version of gcc. It certainly is not something
> you can really use anyway, as using it requires that all users have to
> upgrade: which may be acceptable in some environments, but is certainly
> not an option in most places.

If the feature gives a clear win, it is possible to use it with a
preprocessor check.  To oversimplify a bit:

#if __GNUC_MINOR__ > threshold
... code using the feature
#else
... older code
#endif

Since this conditional compilation gives one more thing to test for, the
developers might choose not to use it unless the win is large enough
to justify it.

Re: kernel-2.2.1-undefined references.

[Jeffrey A Law]

  In message < 199902110155.RAA14069@atrus.synopsys.com >you write:
  > so many insults.  The change in question was not "for no good reason", it
  > was an attempt to decrease the virtual memory consumption of gcc (I don't
  > know how much it helped).  If the change has limited value and harms the
  > Linux kernel, that may be a good reason to revert the change.  It has not
  > gone into a release, only a snapshot.
To clarify, the change was not because c++ memory consumption.  It was to fix
a real bug -- imagine what happens if you have label initializers which are
used by indirect jumps and you inline the function.

See execute/980526-1.c

The C++ inline memory changes are still in the queue, they haven't been
installed yet.

jeff

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> And no, very few others are complaining, because the breakage only
> happened when you used two gcc extensions together ("inline" and address
> of a label). Linux is probably the only thing that actually uses a lot of
> the extensions. 

Unfortunately, this makes it more likely that the egcs development will
occasionally break Linux; we just don't have that many test cases for
interaction between gcc extensions.  When these are encountered we'll
just have to fix them.

I think that it's perfectly reasonable to ask that the change that broke
this be reverted enough so that you can get the function in question
inlined again, and I'm sure that folks like Jeff are eager to assist you
with just that.  I only hope that in the future it can be handled without
so many insults.  The change in question was not "for no good reason", it
was an attempt to decrease the virtual memory consumption of gcc (I don't
know how much it helped).  If the change has limited value and harms the
Linux kernel, that may be a good reason to revert the change.  It has not
gone into a release, only a snapshot.

In the future if a change to a snapshot breaks Linux, please report it as
a bug, and I'm sure it will be treated as high priority.  To avoid another
round of flamage, it's best to indicate clearly that the code relies on
GNU extensions, so that the (rather large) group of people whose main
interest is a good compiler for conforming code won't get bent out of
shape and fill the list with "but the standard doesn't guarantee that
you can do that" mailings.

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> I'm not trying to be unreasonable. I'm just saying that if there is
> a function that is marked inline that can be inlined,

And the case in question is a case where it can't be inlined.  It
isn't that the compiler wants to screw you.  It is just a case where
it is too dumb to comply.

As to the documentation, it clearly states:

  Inlining of functions is an optimization and it really ``works'' only
  in optimizing compilation.  If you don't use @samp{-O}, no function is
  really inline.
  
  Some calls cannot be integrated for various reasons (in particular,
  calls that precede the function's definition cannot be integrated, and
  neither can recursive calls within the definition).
  
  The definition in the header file will cause most calls to the
  function to be inlined.

I don't know how people misread the above.  I find it very clear.  It
says `most' calls will be inlined, not all calls.  It says some can't
be integrated for various reasons, but doesn't say what those reasons
are.  It says that it is only an optimization, not a required
semantic.

What does the phrase `Some calls cannot be integrated for various
reasons' mean to you?  Do you interpret this as a guarantee that gcc
will always inline for you?

Re: kernel-2.2.1-undefined references.

[Bill Kelly]

> Date: Sat, 13 Feb 1999 00:08:06 -0500
> From: Paul Derbyshire <pderbysh@usa.net>
> To: egcs@egcs.cygnus.com
> 
> Christ Craig, give it a rest.  This is a dead horse you're beating.

I think Craig's postings have been top-notch. It's rare when someone
both understands and is able to state so clearly the long-term design
issues he's tried to get across.

:-) His are the only articles I've saved from this thread, filed under:
~/news/c++/egcs.badass

> Some reasonable sane and rational suggestions for solving the problems both with
> Linux and egcs have appeared; someone's found that a conditional compile
> can be used to make the extern inline thing compile and work on every gcc
> by either using __builtin_return_address or the label hack; Linus has said
> the panic code isn't too critical anyways and has apologized for some of
> the tirades earlier in the week; and it seems to be high time this issue
> was let drop on the list; yet I keep seeing more tirades from you every few
> minutes to an hour.
> 
> BTW, did you know that your ISP's mail server was bouncing mail
> inexplicably all afternoon? Was bouncing messages with "Service
> unavailable". Never heard of downtime causing mail to bounce before;
> usually it's deferred. You should have a few stern words with your ISP's
> customer service reps about this; if the downtime had been much longer the
> bounces would have caused yo to be removed from this list and any others
> you're on more than likely. They should just defer the mail.

Yeah something is askew, neither of my local ISP's are able to even
_resolve_ jcb-sc.com.

Bill Kelly
<billk@cts.com>

Re: kernel-2.2.1-undefined references.

[Bryan W. Headley]

Ross Smith wrote:

> From: Per Bothner <bothner@cygnus.com>
> >
> >[Linus wrote:]
> >> I'm not trying to be unreasonable. I'm just saying that if there is a
> >> function that is marked inline that can be inlined, it _should_ be
> >> inlined, because the compiler _never_ knows better than the programmer.
> >
> >Er, the compiler often knows better than the programmer.  That is why
> >we use compilers - to free us from low-level and architecture-dependent
> >decisions.
> >
> >Note you have a rather atypical perspective.  You know the hardware
> >in depth, and you know which instruction sequences will be faster.
> >You probably know (or at least can make an informed guess) if inline
> >will help or hinder the code.  You also sometimes need precise control
> >over low-level code.
> >
> >We cannot design a compiler for the Linux Torvalds' of the world.
> >We have to do what is best for *most* programmers, while still
> >providing the needed tools for the experts.
>
> It occurs to me that the real problem here is that "inline" is being
> used to refer to two slightly different concepts, and some of the
> participants in this thread haven't noticed this and are talking past
> each other.
>
>   (A) inline == "I [the programmer] know exactly what this code is
>   supposed to do at low level, and I have determined that this function
>   must be inline for proper behaviour, so inline it or give me an error
>   if you [the compiler] can't."
>
>   (B) inline == "I [the programmer] believe this code would be more
>   efficient if this function were expanded inline, so please do so
>   unless you [the compiler] have a good reason to do otherwise."
>
> Linus wants (A), but the inline keyword, as defined by ISO C++,
> mandates (B). Exactly what consitutes a "good reason" is a function of
> compiler technology. In many cases, compilers *are* smarter (about
> certain specific things) than programmers, and will quite rightly
> override the programmer's choice. For inline, this is rare today, but
> will get more common until eventually "inline" goes the way of
> "register".
>

No, I heard more than that. Such as, the compiler may opt to make a function
into an inline based on optimization. Which scares the hell out of me, too.

The argument, though, should be telling you that basing a C compiler
front-end on top of a C++ engine is going to become more and more risky.
There once was a time when there was a tight correlation between the C code
and the assembly. With C++, with "hidden" destructors to deal with exception
handling, jump tables to give the feel of class heirarchy, etc., you cannot
say that anymore.

I like Per's comments about not being able to produce a compiler that behaves
like Linus would want. It sort of makes Messrs Kernighan, Richie and Thompson
just a little bit more special than they are already :-)

#include <bryan/has/little/respect/for/ansi/nor/iso/as/they/are/usually/10/years/behind>

--
____               .:.                 ____
Bryan W. Headley - bheadley@interaccess.com

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> I've yet to see *any reference* to the claim that it is *documented*
> that the inline declaration *guarantees* that the function will always
> be inlined.  Even with extern.  That was your assumption, reading
> between the lines...

RTFM.

Remember, we are not talking about ISO C++ here.  We are talking about
*C*, and specifically the GNU "extern inline" extension.  So the M to R
is the gcc manual.

We may have an issue later on with C9X, which may define "extern inline"
to mean something different.

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

>(BTW, I dislike macros too.  C is just too weak a language to get
>much done without them, though.  I had high hopes for C++ around
>10 years ago, but....)

But... what?
C++ is great. Templates, consts, ... no more macros exceptto
controlcompilation.
Now we just have to sit and wait for a compiler to come out that finally
supports the standard completely, from the standard library (including
<limits>) down to proper template linkage. Which some experimental egcs
snapshot is purportedly able to do.

[some deletia]

He didn't want lots of new features. He didn't even want a cross vendor
portable way to get a stack trace. He just wanted a way portable across GCC
implementations to get a stack trace.

>...new architectures, such as massively parallel machines,
>"massively serial" machines, etc.

"Massively serial"? By which you mean what, with thousands of cpu
registers, or terahertz clock rate, or...?


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[TTK Ciar]

  Wow .. can't we all just get along?  It wouldn't be difficult to 
add a command line option to enable the desired (and justifiable) 
behaviour and call it quits.  Tweaking the code in rest_of_compilation 
in toplev.c that calls function_cannot_inline_p() would get us half
way there.  Depending on how exactly it was tweaked, the other half 
of the way might be a little painful, though.  If all you want is for
nonzero function_cannot_inline_p() results (which are in fact verbose 
textual descriptions of the problem -- grep for "cannot be inline" in
integrate.c) to be returned as errors, well, that's really trivial.

  One of the supposed advantages of free software is flexibility and
the ability to give skilled users the control they need over their 
tools.  I'd hate to think we're losing that.

  That being said, I think the current behaviour (ie, silently
dismissing a request to inline) should remain the default compiler 
behaviour just because there are a lot of users who have come to 
rely on this behaviour to fix their broken code, and I don't want
to put up with the screamed ravings of ten thousand incompetent 
programmers when the alternative is to add a switch in our CFLAGS.

  Huge disclaimer:  The above is my opinion only, and has nothing
to do with the official position of Cygnus (if it has one).  I have
little or no influence in getting such a change accepted by the code
maintainers, who might find it objectionable simply because they 
find creeping featurism undesirable.

  -- TTK 

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

>Read archives of comp.compilers and related works if you really
>want to learn why "C is closer to the machine than Fortran" is,
>for all intents and purposes, something between a myth and a self-
>fulfilling prophecy.  And why "volatile" is a great example of a
>supposedly necessary feature that, linguistically speaking, makes
>almost every computer language that incorporates it *worse* than
>it would be without it.

I don't think so. How the hell else can you write C code that works with
data that changes asynchronously, e.g. because of multiple threads or
because of hardware or interrupts or signal handlers or...

The choices are:

1. Don't optimize at all -- UNACCEPTABLE
2. Mark data the compiler isn't to optimize into registers and about
   which it isn't to make any assumptions regarding the value being
   consistent.

The latter gets us 'volatile'.

Which do you choose?

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Ross Smith]

From: Per Bothner <bothner@cygnus.com>
>
>[Linus wrote:]
>> I'm not trying to be unreasonable. I'm just saying that if there is a
>> function that is marked inline that can be inlined, it _should_ be
>> inlined, because the compiler _never_ knows better than the programmer.
>
>Er, the compiler often knows better than the programmer.  That is why
>we use compilers - to free us from low-level and architecture-dependent
>decisions.
>
>Note you have a rather atypical perspective.  You know the hardware
>in depth, and you know which instruction sequences will be faster.
>You probably know (or at least can make an informed guess) if inline
>will help or hinder the code.  You also sometimes need precise control
>over low-level code.
>
>We cannot design a compiler for the Linux Torvalds' of the world.
>We have to do what is best for *most* programmers, while still
>providing the needed tools for the experts.

It occurs to me that the real problem here is that "inline" is being
used to refer to two slightly different concepts, and some of the
participants in this thread haven't noticed this and are talking past
each other.

  (A) inline == "I [the programmer] know exactly what this code is
  supposed to do at low level, and I have determined that this function
  must be inline for proper behaviour, so inline it or give me an error
  if you [the compiler] can't."

  (B) inline == "I [the programmer] believe this code would be more
  efficient if this function were expanded inline, so please do so
  unless you [the compiler] have a good reason to do otherwise."

Linus wants (A), but the inline keyword, as defined by ISO C++,
mandates (B). Exactly what consitutes a "good reason" is a function of
compiler technology. In many cases, compilers *are* smarter (about
certain specific things) than programmers, and will quite rightly
override the programmer's choice. For inline, this is rare today, but
will get more common until eventually "inline" goes the way of
"register".

But kernel programming (and a few other cases such as embedded systems)
is a special case, with unusual performance and low-level behaviour
requirements. A "gimme inline and keep your opinions to yourself" (i.e.
option A) keyword is really necessary. And the problem is that GCC has
traditionally (since before it included C++) used plain "inline" for
this, whereas ISO C++ (and, I believe, the upcoming C9X standard)
specifies option B.

As far as I can see, there are four possible resolutions:

  (1) Decide that EGCS will use the traditional GCC interpretation of
  "inline", i.e. option A. This would be unpleasant for non-kernel
  programmers, and while it wouldn't strictly violate the letter of
  the C++ standard, it would certainly violate the spirit.

  (2) Provide a compiler switch that indicates whether "inline" should
  have the traditional GCC meaning (option A) or the ISO C++/C9X
  meaning (option B).

  (3) Give "inline" the ISO C++/C9X meaning, and provide a new keyword
  (e.g. "__force_inline") that has option A semantics for the kernel,
  embedded system, etc. programmers. IMHO this is the best solution.

  (4) Use option A for C and option B for C++. Ugh.

(P.S. #insert <std_rant_about_americans_who_say_ansi_instead_of_iso>)

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
                               * * * * *
    To err is human. To really screw up requires the root password.

Re: kernel-2.2.1-undefined references.

[craig]

>On 12 Feb 1999 craig@jcb-sc.com wrote:
>> 
>> >To _me_, "standard C" has not been important at all. I'm _more_ than happy
>> >to use gcc extensions, because I think they are worthwhile in the kernel. 
>> 
>> That means, like I already said, you have to be prepared for a very
>> bumpy ride.  You've shown that you have trouble coping with that.
>
>Umm..
>
>I had no problems with gcc features for about six or seven years of Linux
>development. These things simply didn't use to happen: despite upgrading
>_major_ versions of gcc (when Linux started we were using gcc-1.40), for
>those six-seven years there weren't really any changes that I ever had
>problems with. 

Which means, what, exactly?  That you therefore can claim some kind
of *ownership* of the exact behavior of gcc in the presence of
all sorts of extensions, regardless of the degree to which they're
clearly specified and documented?  Sorry, you *should* know better.

>There were tons of code generation bugs over time, but hey, I _expect_
>bugs, and while compiler bugs are sometimes really hard and nasty to find,
>I don't complain too much: I report them, and I tell people not to use
>certain versions. I may be grumpy for a while because I spent ages looking
>at a bug that didn't turn out to be mine, but I never get the feeling that
>I should really dislike the compiler people. 

Given how you've treated the egcs developers lately, for daring to:

  -  Offer you a free compiler

  -  Offer you free upgrades

  -  Offer you free responses to bug reports

  -  Offer you free bug fixes

  -  Offer you free improvements to unclear documentation

  -  Offer you free advice as to how to improve your code to make
     it more immune to likely changes to egcs code development

I think we're *all* grateful you don't feel you should actually
*dislike* us.

>The reason I have been complaining so much lately is that I think that the
>egcs development has lost that stability. Again, never mind code
>generation bugs, I'm talking about _interface_ stability. I've had much
>more problems in the last year than I had in the seven years preceding
>this.

Yet, that's *exactly* the kind of symptom I would *expect*, speaking
objectively, given the problems *I've* been claiming exist here.

In short, you're saying that you decided long ago to depend mightily
on particular implementation details of gcc, despite not having a
clear specification constituting a promise that those details would
not change in future versions of gcc.

For several years, as gcc development slowed down more and more, including
around two years when *no* major changes were made in released versions,
you experienced no problems.

Then, when the floodgates of development were opened, and development
increased to a heretofore-unknown level of activity, suddenly you
ran into nasty surprises as the (sometimes-obscure, like regparm)
extensions you relied upon stopped working as they used to.

Linus, there is *nothing* surprising in that, and *nothing* that
suggests the problem is due to the attitude of the egcs developers,
or the pace of egcs development.  Even if egcs had been "perfectly"
developed in this regard, the results would have been better
documentation of the limitations of "extern inline" and addresses
of labels, which you probably wouldn't have noticed changed, and/or
vehemently disagreed with the "direction" in which egcs is going.
(By proof, I offer the fact that, now that we're fixing this, you're
*still* arguing.)

There are *plenty* of people who are quite happily continuing to use
egcs on their codes, as it evolves, because *they* wrote *their* codes
to properly use the pertinent languages.  (To the extent they're
not happy with bugs, I suppose they're wondering why we're wasting
our time accommodating your use of obscure extensions when we could
be making specification-conforming code actually work in the first
place, go faster, be smaller, etc.)

>This may actually not be due to technical reasons as much as simply due to
>a different open development model - it may just be that more people see
>"partial" work, and some of that partial work breaks stuff. Fine - I like
>open development myself, and I use it. But when somebody complains to _me_
>that I broke old interfaces, I consider that a bug unless I have a very
>very strong technical reason to tell people that I simply _cannot_ support
>some old interface any more. 

You cannot support the "extern inline" interface anymore, as a promise
that inlining will happen.  There, I said it, others have said it,
and the strong technical reasons are that *gcc* will not promise it
to you, nor will any *other* compiler that undergoes any useful
development over the next 10-20 years.

>In contrast, on this list, when people complain that egcs breaks existing
>code, the answer is "shut up and live with it" - and then they Cc: me on
>the damn thing. And that's why I get so upset, and why these flame-wars
>erupt. 

I didn't see those answers.  FIrst thing *I* noticed was *your* flames.

If you want to send along a few pointers to the earlier posts, I
wouldn't mind reading them to see what you're talking about.

>"Shut up and live with it" is not a way of caring for your customers. And
>creating the best compiler in the world is not just about code generation:
>it's about supporting the people that use it, too. 

I agree with that.  I'm not claiming egcs is perfect in this regard.

What I *do* know is that you've caused many of us to burn lots of time
on what was a non-issue, long-ago dealt with, but ignored by,
apparently, at least one Linux developer in the past.

And if you think it is *our* job to support *you*, ask yourself how
many donations you've made to egcs developers lately, and compare
that to your recent tendencies (not just in this thread) to accuse
them of breaking your code and then not listening to their explanations
regarding how you can avoid these problems in the future.

>I could change my kernel interfaces and tell people that "shut up,
>recompile, and be happy". Trust me, that doesn't work when you have a
>serious project that you expect others to be serious about too. I make
>_damned_ sure that I don't break binaries, and when I do it by mistake I
>have egg on my face and I fess up to screwing up. 

Look, I probably care more, and perhaps know more, about preserving
the integrity of interfaces to products like kernels and compilers
than most anyone on the egcs or Linux development teams.  I say that
not so much because of my technical abilities vis-a-vis programming
(which aren't bad), but because of my understanding that you don't
*get* integrity of interfaces without *first* starting with a
solid design, specification, development, and *documentation* effort.
And I've got a pretty good understanding of what *those* entail,
and how rarely they're practiced in much of the software industry.

That's why I've taken the time to so *carefully* explain to you,
and others, exactly why your assumptions about "extern inline" are
wrong, and even if you manage to wrangle a promise about to preserve
them from some well-meaning egcs developers *today*, that promise
will someday be broken.

Yet, because I've *dared* cross the Great Linus Torvalds, you've
taken to trashing *my* posts as "silly", claim I'm posting "sh*t",
"crap", and so on.

There's not a *single thing* I've said in these posts that has been
shown to have been even remotely incorrect, aside from my realizing
I might have confused you and David Miller in the emails about
this issue six months ago.  Much of what I said is valuable guidance
for people working on projects that have nothing to do with either
egcs or Linux, and represents the understanding I've gained by working
on OS, tool, interface, and compiler development and documentation
for nearly 30 years now.

But, to you, it means *nothing*, because you apparently don't value
actually using *documented interfaces* correctly in the first place,
meaning that if an interface isn't clearly specified, don't make
assumptions about it.

>On this list, nobody 'fesses up to screwing up any more. And that's sad. 
>It makes the egcs project look less serious, and more like a bunch of
>people that just want to play at making a commercial-grade compiler. 

We admitted the documentation needed improving.  I *think* that has
happened already (if not, I'll do it myself).  And we apparently
fixed the buglet that triggered the bugs in your code, so you can
ignore those for awhile longer if you want.

If that isn't admitting to screwing up, I don't know what is.  I know
it isn't exactly *what* you think we should have admitted to.  But
if we admitted that the whole problem was the the compiler needed
to *always* ensure inlining of "extern inline", you'd *love* that
response, pat us on the heads, and say "good jobs", but we'd have
implicitly made a promise we could not possibly keep down the road.

But it's *our* compiler.  It's *our* documentation.  It's *our*
language specification.  Therefore, *we* get to decide which of
these are broken, when conflicts like this arise.

I'm pretty confident the right decision has been made.  I'm absolutely
*certain* you haven't presented sufficient reasons, to date, to have
made a different decision.

And it's also quite clear you have *zero* respect for the decisions
made by us about our product.  So if you like them, you're happy, and
if you don't, you flame us, and anybody like myself who comes along
and tries to explain them to you in more detail.

So all your PR efforts at trying to rah-rah us into being better
compiler developers don't amount to much, since we can all see
what you *really* care about: getting us to do exactly what you say,
without question, without thought, even if that includes making
promises we *know* we can't keep.

If you *really* value what we're doing here on the egcs project,
you'll not say *one more word* on this topic, except perhaps for
offering some pretty serious apologies, if you've got the integrity
to do that.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> Read archives of comp.compilers and related works if you really
> want to learn why "C is closer to the machine than Fortran" is,
> for all intents and purposes, something between a myth and a self-
> fulfilling prophecy.

Of course it is a "self-fulfilling prophecy" -- given that a major use of
C is in embedded systems, the customer base believes that C (rather, at
least some C constructs) is "close to the machine" and will demand the
ability to do things like write code that interacts with memory-mapped
hardware in C, and compiler vendors will respond to this demand (in
practice, C++ is just as "close to the machine" in this sense as C).  It
appears that you don't like this, and I know that many of the academics
that hang out on comp.compilers object to it (but then, they don't like C
-- some of their reasons are valid, some are merely prejudices).  But
these are only opinions.

And please drop phrases like "if you really want to learn" ... I have
extensive experience with the issues involved.

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

In message < 36BF8D9A.B14ABAE9@interaccess.com > you write:
> 
> It all depends on whether you are making an application compiler or a
> platform-independent assembler, which C originally was. If I wrote some
> code where I expect measurable time rolling and unrolling a stack frame
> going into a function, and it's not there because of an auto-inline
> optimization, I'd be screaming. 'volatile' functions are too weird at
> this late date.

C was never meant to be a "platform-independent assembler", the Bell
Labs guys already *had* BCPL.  Instead it was intended as a highly
efficient systems programming language.  You couldn't even say that it
was intended to be platform independent, since so much of the language
was explicitly left platform-dependent in order to promote
efficiency.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 9 Feb 1999 craig@jcb-sc.com wrote:

> >Why don't you just remove "inline" completely, then?
> 
> Because it works just fine, and as documented, for 99.9999% of the
> uses to which its put in code compiled by gcc?

Right. So why break it then?

		Linus

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

In message < Pine.LNX.3.95.990208160839.433A-100000@penguin.transmeta.com > you w
rite:
> 
> 
> On Mon, 8 Feb 1999, Lee Iverson wrote:
> > 
> > It occurs to me that we do, in fact have an acceptable method of
> > *guaranteeing* inlining of a *function* in gcc.  That is a combination
> > of a macro and the "Statement Expression" extension.
> 
> Sure. 
> 
> Why don't you just remove "inline" completely, then?
> 
> It's apparently ok to break documented and existing behaviour of "inline". 
> Go read the gcc documentation about "extern inline", the whole thing is
> _designed_ to be a much more readable form of #define. 
> 
> Oh, well, I don't care any more. Make up your own rules, and break
> documented behaviour. 

I've yet to see *any reference* to the claim that it is *documented*
that the inline declaration *guarantees* that the function will always
be inlined.  Even with extern.  That was your assumption, reading
between the lines...

That said, the documentation *does* clearly seem to strongly imply
such a guarantee.  The hedging language that should be there *isn't*
except for the single line: "Note that certain usages in a function
definition can make it unsuitable for inline substitution."  Clearly
not as prominent as it should be.

Of course inline is supposed to work, but as you've heard this is
largely a question of *reliably* generating correct code and as in the
past *your assumptions* about what the compiler should be doing rather
than objectively documented behavior.  The compiler may not be living
up to your expectations, and I know that it hasn't in the past, but
just as in some of those cases (e.g. the asm clobbering issue or the
inline+label addresses), the problem is that you are relying on
behaviour that is either undocumented and thus not guaranteed or
falling between the cracks of the implementation.

I think this is a case where the documentation is misleading.  It does
suggest that inlining is not guaranteed, but IMO not as prominently as
it should.  That is what you've been bit by, *not* a guarantee that
isn't being honoured.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Wed, 10 Feb 1999, Jamie Lokier wrote:

> Jamie Lokier wrote:
> > H. Peter Anvin wrote:
> > > Oh yes, __builtin_constant_p() really, really ought to work properly
> > > in an inline...
> > 
> > It does.  See egcs-1.0.3.
> 
> Bugger, I was wrong.  Sorry Peter.

It works in development versions of egcs, but as far as I know of it does
not work in _any_ released version of gcc. It certainly is not something
you can really use anyway, as using it requires that all users have to
upgrade: which may be acceptable in some environments, but is certainly
not an option in most places.

The same is true of certain other features like __builtin_return_address() 
(which _does_ work in egcs-1.0.3 I've been told, but doesn't work in many
other versions) which makes them essentially a non-issue in production
environments with multiple versions of gcc. It's good that these things
evolve and get fixed, but the fact that they have gotten fixed does NOT
mean that people can just start depending on them - that will happen much
much later. 

This is one reason why it's so important to _not_ break backwards
compatibility if at all possible: even if you introduce a new feature that
makes an old feature unnecessary, you can't just force all your users to
upgrade overnight, and you should expect people to use old and new
versions concurrently - so the old feature has to stay (not forever, but
certainly for at least one major release - which for most bigger projects
implies at least a year of "migration time"). 

No, I don't enjoy it either. Maintenance is not especially exciting or
interesting, but it _is_ important. Expect people to rely on
__builtin_constant_p inside inline functions in another two years or so.

		Linus

Re: kernel-2.2.1-undefined references.

[craig]

>Why don't you just remove "inline" completely, then?

Because it works just fine, and as documented, for 99.9999% of the
uses to which its put in code compiled by gcc?

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Lee Iverson wrote:
> 
> It occurs to me that we do, in fact have an acceptable method of
> *guaranteeing* inlining of a *function* in gcc.  That is a combination
> of a macro and the "Statement Expression" extension.

Sure. 

Why don't you just remove "inline" completely, then?

It's apparently ok to break documented and existing behaviour of "inline". 
Go read the gcc documentation about "extern inline", the whole thing is
_designed_ to be a much more readable form of #define. 

Oh, well, I don't care any more. Make up your own rules, and break
documented behaviour. 

		Linus

Re: kernel-2.2.1-undefined references.

[craig]

>This whole thread only serves to fill all our mailboxes with a bunch
>of name-calling and nitpicking.  It does not help the development of
>gcc or linux (I assume the reason we are all subscribed to this
>listserv is to _help_ the development of gcc, no?).  It is the
>software development equivalent of ``my dad can beat up your dad!''.

Sorry, I'm not here to play the "let's all get along" game.

If Linus persists in assuming he'll be promised actual inline whenever
he says "inline", he'll continue making Linux *worse*.  If he learns
how to better engineer the code within Linux to at least work within
reasonable tolerances of how gcc extensions behave, he'll make it
*better*.

As I said, this is at least the second time around with him on this
sort of thing.  *He* has chosen to not get along, and to repeatedly
disregard the solid advice he's been given.

>Basically (without all the name-calling), the developers of egcs found
>that combining two gcc extensions did not produce reliable code.  So,
>they took the easy fix: don't allow them to be combined.  This broke a
>significant amount of code for one user, Linus (granted he is not just

As far as I can tell, it broke no *correct* code at all.

>_any_ user, nonetheless ...).  I am sure other people who depend on
>these gcc extensions will also feel the pinch.  This is all fact,
>everything else that has been said is superfluous.

Sorry, I disagree.  Much of what I said, if actually paid attention
to, would help people produce more solid code, and perhaps a more
solid compiler as well.  I don't appreciate being told everything
else I said was "superfluous".  Is this your idea of trying to get
people to stop "name-calling and nitpicking"??

>That being said, is there anything we can do together to improve the
>situation for all of us?  Obviously the combination of these
>extensions worked sometimes.

AFAICT, they still worked, for correct code.  And someday gcc will
outright *ignore* "extern inline" sometimes for even ordinary
functions, because someday it will be an even better optimizing
compiler, which is what it is advertised as (as versus a macro-based
code generator, which is what some people seem to treat it as).

>Is there any way to find out when it
>works and when it doesn't?  It should be a deterministic problem, no?

It was and is working fine, AFAIK.  Bad code that depended on the
generated code having certain undocumented properties stopped working,
and on the whole we'd like to try triggering that sort of thing,
but it's something we can't always prevent, and the world would be
a better place if people who wrote bad code like that took well-
intentioned advice to stop.

>Perhaps Linus has some cases in his code where he knows it works.
>Perhaps other has incidences where it doesn't.  Is there not time to
>address these issues now?  Can it be put on the TODO list?  Can we at
>least agree on how to warn/error when gcc can't comply with what the
>programmer wants?  There has to be something that can be done to make
>the compiler (and the atmosphere on this thread) better.

There apparently already was, -Winline, and it wasn't being used.

The atmosphere on this thread will get better only once Linus retracts
his claims that it was *gcc* that broke *his* code, and accepts
that his code was wrong.

>Admittedly, I have not the knowledge nor the expertise to investigate
>these options myself (I am but a lowly chemical engineer).  I
>apologize for this (my only intention is to help).

I have rarely seen anybody step into an argument in the way you've
done actually succeed at helping.  Playing "good cop" when your
tactics include casting aspersions on the points people like
myself have taken our time to carefully make frankly does *not*
help.

But it sure seems to make some people *think* it helps, and I guess,
these days, that's all that matters.  Kinda like those executives
who felt it was better to "get along" with the folks their company
was contracting for than to tell them bad news about risks involving
their products.

Of course, the result was the Challenger explosion and seven
people killed, but the nice motivation to "get along" was all that
mattered, right?

>Let's turn this thread around, discuss some specifics, and get
>something done.

The buglet in gcc has, I gather, already been fixed.  I haven't
gotten the impression the underlying bug(s) in Linux have, or
will, get fixed.

If that's right, this problem will occur again, sooner or later.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

In article < 19990210133236.30212.qmail@deer >,  <craig@jcb-sc.com> wrote:
>>On 9 Feb 1999 craig@jcb-sc.com wrote:
>>
>>> >Why don't you just remove "inline" completely, then?
>>> 
>>> Because it works just fine, and as documented, for 99.9999% of the
>>> uses to which its put in code compiled by gcc?
>>
>>Right. So why break it then?
>
>By your apparent standards, it always *was* broken, because inlining
>didn't always happen.

No.

gcc _did_ use to always inline if it at all could do so.  There were
cases that made it unable to inline, simply because the code itself was
not conducive to inlining.  Those were _technical_ reasons for not
chosing to inline something, and completely and utterly understandable. 

For example, not inlining a recursive function is just obviously the
right thing to do (yes, in theory you could try to make it iterative,
but if the programmer gave the compiler a recursive function then it's
the _programmer_ who is responsible for it, and nobody really expects
the compiler to do miracles).

>Yet, as I said, even then, it works just fine, and as documented,
>for 99.9999% of the uses to which it is put in code compiled by gcc.

No. It used to work for 100% of the caaes gcc could handle.

The change broke that.

It used to be a feature you could depend on.

The change broke that.

Yes, the documentation had hedges to handle the real cases (like
recursion etc) where inlining just isn't feasible, but the fact that it
hedged its bets doesn't change the fact that people like me used to be
able to rely on the compiler to do what it was asked to do.

If it was a case of "oh, gcc used to have a 50-50 policy on when to
inline, and the change made that a 40-60 policy", then it would have
been much more palatable. But it wasn't. It was a case of 100% success
being turned into "I wonder what the hell they'll break next time
around". 

Repeatability is good.  Random changes that break existing behaviour for
no technical reason is bad. 

>(That's not surprising, since gcc is, generally, based on standards
>such as ISO C, which presumably make it much clearer that "inline"
>is, like "register", a mere hint.)

"extern inline" is a documented gcc extension. It may be covered by ISO
C these days, but it didn't use to be.

"address of a label" is a documented gcc extension, and is NOT covered
by any C standard (pending or accepted) that I know of.

As such, the people who brought up "standards" as an argument for
changing the behaviour are fairly hypocritical: it's a good argument but
in order to hold water it has to be _relevant_. 

		Linus

Re: kernel-2.2.1-undefined references.

[craig]

>The emails you quote are from the previous time this happened. As now,
>nobody actually suggested a good working way to do what we wanted to do
>without just completely resorting to macros (and I've already explained
>why I dislike macros). 

But, even if Linux developers didn't consider any of the proposals
as "a good working way", that didn't mean they were free to ignore
the *warnings*, which accompanied the proposals, about the dangers
of continuing to rely on the extensions in question as they were doing.

(BTW, I dislike macros too.  C is just too weak a language to get
much done without them, though.  I had high hopes for C++ around
10 years ago, but....)

>What you suggested then isn't any better than what you're suggesting now: 
>implementing new features in gcc doesn't obviate the need to be able to do
>the same thing with old code. And implementing a back-trace by hand is
>architecture- and compiler-dependent, which is silly because when that
>breaks due to compiler changes you'd just complain that we should do
>something else. You can't have it both ways, Craig. 

Of course, the code to do a limited back-trace would have to be part
of the system-specific, perhaps even compiler-specific, code that
pretty much any OS has.  I didn't imagine otherwise -- sorry if you
thought I was saying gcc somehow offered a feature to portably
obtain stack-trace information!

I do think there might be some feasability, depending on what it
is you're trying to accomplish *generally*, in the idea of
special pre-processing and/or post-processing of the source code
and assembler output.  It wouldn't be portable, but it might be
much more robust than anything we can feasibly do for you, and
more responsive to changes whenever your needs change, making your
project more tolerant of changes to gcc (for example).

But I don't know enough about what you need, on the whole, to really
offer any specific suggestions at this point.  I can only guess.

And that's part of why I, personally, would tend to resist adding
a new feature because you say it'll help you.  Not to be disrespectful
to you specifically, but generally, I find it is often the case
that a user asking for a new feature, in a situation where I don't
fully understand their need for it, won't find that new feature
completely addresses their problem, once I implement it.  So they'll
come back and ask for yet another new feature, to address the corner
cases or whatever they didn't previously think about.

In the end, if I'm not careful, I'll implement a handful of features
just for that kind of customer that are increasingly difficult for
users to really make good use of, hard for me to maintain, and which
don't really fully address the original problem.

>Face it: what Linux does is entirely reasonable, trying to get a backtrace
>in a architecture-independent way. Yes, it bit us, but it was certainly
>not an unreasonable thing to do.

I wouldn't call it "unreasonable".  But I think the implementation
of something like this should have been much more carefully studied
up-front, and/or, upon discovering it didn't always work if the
compiler had subtle changes made to it, an alternative quickly
looked-for, rather than blaming the compiler for changing.  (Though,
I still believe, we like to *know* when buglets like this creep in,
e.g. stuff stops inlining that really should inline in a reasonable
compiler.)

That relates back to my point about tolerances.  *We* want to know
when our compiler gets *near* the boundaries of its published
tolerances (and certainly when it exceeds those boundaries), but
we also want people to use it in ways that *accommodate* those published
tolerances, rather than assuming we'll always be able to keep it
within some unpublished, tighter tolerances.  Of course, they
can choose to ignore our advice, but they have to understand that
our priorities usually put bringing the compiler to *within* published
tolerances higher than *tightening* the compiler's tolerances
(which constitutes a promise of future performance and behavior).

This means you might get no help from the compiler doing what you
need.  That's unfortunate, but not necessarily the fault of the
compiler -- it might just mean the problem is better solved outside
the arena of the generation of optimized code from an "as if" language
like C.

>Do you really think it's unreasonable to ask for some way of forcing
>inlining, when the compiler obviously can do it? It doesn't have to be
>"extern inline", if you're afraid of polluting a future standard
>namespace. 

I think the complexity of just figuring out what exactly is *meant*
by "forcing inlining" probably greatly exceeds the benefits of
doing that, implementing the resulting specification, and maintaining
the it down the road.  For example, just how many copies of a
given invocation of inlined code end up in RAM; whether a
short-call interface may be used for inline code to quickly gain free
registers in a register-window machine like SPARC; whether
addresses of static variables are guaranteed to be unique across
all of the inlining "sites"; whether visible code-generation differences
between an inlined "maybe inline" and "always inline" would be permitted...
these would need to be nailed down, and not just by looking at the current
implementation, but by looking at what might be appropriate in the future,
for new architectures, such as massively parallel machines,
"massively serial" machines, etc.

Further, as I said in another post, which perhaps didn't go directly
to you, the C language upon which GNU C is based follows the "as if"
rule.  Much of the implementation of gcc assumes the "as if" rule.

Every extension and command-line option added to work around the "as if"
rule tends to not work very well and make gcc less maintainable
overall.

And, the "force inlining" phrase almost certainly connotes the idea
that "I don't mean *as if*, I mean *do exactly what I say*".  Though
there's no consensus likely to emerge anytime soon on exactly *what*
is meant by that, in implementation terms that make sense across
all current and future processors targeted by gcc.  (Please don't
say "it just means compile the code in line".  That means almost
*nothing*, just as "inline" itself means almost nothing!  For
your purposes, you'd need to offer exactly what visible semantics
you expect to take hold when forcing inline over not forcing inline,
or not inlining.)

In that sense, frankly, even if you *did* like using macros, you
wouldn't get a 100% guarantee of inlining, just like you wouldn't
when using any form of "inline".  That is, the compiler is free
to implement your repeated macro invocations as calls to a single
procedure, as long as they worked "as if" they were simply
code-generated as you'd currently expect.  Who knows, `-Os' might
someday be able to do that sort of thing, and people would certainly
want it to be able to.

I won't speak for the gcc developers who'll probably make the
decisions, but it's generally not wise to introduce extensions
outside the "zeitgeist" of a product just to satisfy a single
customer.  Even if you make that customer happy, it will be
only for the short term, in almost every case.  And I think the
"zeitgeist" for gcc is, despite a plethora of apparently "as-if-less"
extensions, strongly along "as if" lines.

So, is it "unreasonable" to ask for this?  No.  It's not unreasonable
for us to say "no", either, though.  If you haven't studied all
the code that gets involved in making inlining work, and making
subsequent processing phases properly account for inlining (in
terms of producing correct debugging info and so on), you might
take a moment to do so -- and then you might see while, on the whole,
it could indeed be unreasonable for us to decide to offer the
feature, even based just on how gcc *currently* does inlining and
ignoring how and when it might do so in the future.

But, that's for us to decide.  Even if *we* decide it's unreasonable
to provide the feature, that does *not* mean, IMO, that it's
unreasonable for you to ask for it.  Your job isn't to think
about the long-term viability of gcc, although I think we prefer
it when users give that some consideration *before* asking for
new features.

After all, it seems that much of this current debate stems from
one particular extension -- addresses of labels -- that seemed
entirely "reasonable" to add, long ago, and which has proved
handy, on occasion.  I think it's likely that the difficulties
that extension has caused exceeds the benefits it granted, compared
to if it hadn't been introduced in the first place.  (Maybe a
more Fortran-like feature, a quite simple but limited form,
would have been a better alternative, though even Fortran's
assigned GOTO has caused lots of pain over the decades.  And
it wouldn't have been useful for the skb_put type of case.)

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[craig]

>On 11 Feb 1999 craig@jcb-sc.com wrote:
>> 
>> >"address of a label" is a documented gcc extension, and is NOT covered
>> >by any C standard (pending or accepted) that I know of.
>> 
>> So why are you using it?  Why would you design a product to so
>> completely depend on the correct interaction of a variety of
>> extensions supported by only one compiler out of so many choices
>> on the market?
>
>Are you being stupid or argumentative? 

Actually, I was curious.  Your extreme reaction at gcc not behaving
exactly the way you wanted and as it had in the past suggested
you might not be aware of the implications of using such features,
despite having been (IIRC) burnt by this before.  I was attempting,
among other things, to educate you (and others reading this thread)
as to some of those implications.

But go ahead, cast your aspersions on my motivations for taking time
out of my busy schedule to try to 'splain this stuff to you.  Obviously
a huge waste of time, but I factored that in, figuring *somebody*
out there on the Internet might learn from these discussions.

(I've spent much of my career offering explanations like that.  I'm
almost *never* wrong in those cases, but I have taken a lot of heat
from people who see only the short term.  I remember, over a year ago,
trying to explain to a roomful of numerical engineers why a certain
design being proposed for new Fortran features was actually dangerous,
because instead of causing people to make mistakes 50% of the time,
it would cause them to do so more like .5% of the time, make the
mistakes much harder to detect, and thus lead to more actual errors
in deployed code.  They thought I was crazy to reason that way.  I'm
thinking of sending your recent email to them, since you are a great
example of the sort of person that considers 50% failure *better*
than .5% failure in many cases, and I prefer to engineer products
to accommodate that viewpoint, since I somewhat share it, especially
when it comes to stuff involving man-machine interfaces, like gcc.)

>To _me_, "standard C" has not been important at all. I'm _more_ than happy
>to use gcc extensions, because I think they are worthwhile in the kernel. 

That means, like I already said, you have to be prepared for a very
bumpy ride.  You've shown that you have trouble coping with that.

Please learn to adapt to the reality of what happens when you use
cutting-edge, poorly-tested extensions in a compiler undergoing
rapid development.

>So "address of label" is a documented feature of the only compiler I
>compile the kernel with.  As is "inline". And my argument was that
>_neither_ of those features were mentioned in any C standard ("inline" has
>since been added to the proposed standards) - but they were very much
>mentioned in the gcc documentation.

Oh, I *thought* your argument was that, if any release of gcc did
not support the combination of the features in exactly the way
*you* expected, despite not being documented to do so, that
meant *gcc* broke your code.

>Ergo, ANYBODY who uses "standard conformance" as a reason for supporting
>their argument just needs to think twice. That was my only argument.

Okay.  I must have misread your earlier posts, including the one to
me, which kept saying things like "what are these [gcc/egcs] guys
going to *break* next?" [emphasis added].  I apologize.

>I'm
>just trying to show people how silly it is to say that "oh, the standard
>says that 'inline' is just a hint", when the current C standard says
>nothing of the sort at ALL.

I didn't realize that was *all* you were trying to say.  I *thought*
you were also trying to say that a change to gcc's decision-making
process as to whether to actually inline an "inline" function
constituted a bug in gcc, rather than a bug in code that somehow
depended on the inlining actually happening.

>[ rest of your silly email removed - you seem to be arguing against using 
>  gcc in the first place. I just want to make sure that gcc continues to
>  be usable and good for Linux ]

It would be, if Linux didn't make use of so many extensions, as I
explained earlier, in the portion of my email you call "silly".

IIRC, I've occasionally suggested, on USENET, that Linux shouldn't
depend so much on gcc's peculiar characteristics, in the past.  Though
I'm a big fan of gcc/egcs and GNU software in general, from an
engineering standpoint, keeping Linux at arms' length from gcc-specific
extensions would be better for Linux, and I think it'd be, in the
long run, better for gcc as well, because it'd tend to encourage
more general optimizations in gcc, rather than having Linux rely
so much on hand-coded use of extensions to get faster code.  (That's
a stretch, though, for applications like kernel-code generation,
I realize.)

I guess your only motivation is to make gcc better for Linux, but
not make Linux more robust by lessening its dependencies on
particular code-generation strategies used by any particular
version of gcc.

Me, I'd like to see *both* gcc and Linux be usable and good.

gcc, being an optimizing compiler, will someday simply ignore
some instances of "inline" entirely, and use procedure calls instead,
unless it dies for lack of interest first.  That's because inlining
a procedure does not always make for the most optimal code.

(It's obvious enough why, when `-Os' is specified, since that
means optimize for space.  It's less obvious otherwise, that
avoiding inlining will tend to reduce the Icache footprint
of the generated code sufficiently to actually make it go
faster than if inlining was naively done.)

But the larger problem is that you seem to think that, once
a behavior is observed, it is guaranteed in future versions of
that product, even though not clearly documented.  You would
do well to learn the lesson that this is not true, just as
a good engineer knows that, no matter how many widgets he's
seen exactly .542cm wide, he'd better take seriously the
published specs for them that say ".542cm +/- .005cm" and
not design his product to *assume* exactly .542cm for all
future widgets.

Tolerance isn't just for the political-correctness crowd.  It
has real meaning, and, when properly employed, real value
in engineering, including software design.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[craig]

>> And, note, C doesn't really make provisions for writing "close to the
>> machine" code any better than Fortran.
>
>You are incorrect, I'm afraid.  What Fortran construct corresponds
>to "volatile", which is in essence a model for a memory-mapped device
>register?

I stand by my original statement -- including the part you didn't
quote in my email about "volatile" -- but I'm not about to argue this
anymore.

Read archives of comp.compilers and related works if you really
want to learn why "C is closer to the machine than Fortran" is,
for all intents and purposes, something between a myth and a self-
fulfilling prophecy.  And why "volatile" is a great example of a
supposedly necessary feature that, linguistically speaking, makes
almost every computer language that incorporates it *worse* than
it would be without it.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[craig]

[People tired of my explanations can skip to the bottom for a question
that is actually *pertinent* to the underlying issue.  And, no, this
issue has not been "solved" per se, though some of the specifics have
been, for the time being, I gather.  Search for "Getting back".]

>Indeed. Right now, to me, it seems like there is _no_ sane way to do
>what I want to do, and rely on what gcc will actually do. This is the
>result of having a bad definition of what things do.

Well...I look at it as the result of having a product (gcc) that
is trying to serve one kind of need and thus isn't really a good
fit for other kinds of needs.

>This is why I objected to the early suggestion to just make the
>documentation even more uncertain on exactly what "inline" did.  I think
>the problem in the first place was documentation that said "almost" and
>"mostly" and "maybe" and "in a blue moon". 

It should have been, and will become, even more vague, and intentionally
so.  The "as if" rule should be more clearly alluded to in the gcc
docs; meanwhile, programmers reading docs about extensions to any
compilers should *assume* the "as if" rule still applies (in the sense
that it applies to the underlying standardized language) unless clearly
documented otherwise.

At least, I think this is the direction the gcc developers would choose
to go, as it avoids the problems resulting from gcc overcommitting
to a particular implementation of "inline" that will be clearly
suboptimal someday, speaking from a SWYM perspective.

>When you have documentation like that, you can't but rely on
>implementation, because the documentation doesn't actually give you
>anything to depend on.  And then we end up in a situation where people
>like me depend on implementation and implementors point fingers at bad
>documentation. 

The idea is to not rely on particular implementations compilers choose
*at all*, or, if you must for some extra-linguistic reason, you have
to take on all the responsibilities that entails.  In other words,
if the compiler developers have not *guaranteed* you a particular
behavior given a particular combination of language constructs, now
and forever, don't rely on it, or, if you do, plan for the day when
it stops working as you expect.

I'm not saying that's easy.  :)

>Testability goes to hell too. 

Um...no, it's actually much easier in the end, because the compiler
is considered to "work" as long as it meets the specifications for
the language (which equals standard + specified extensions), rather
than do that *plus* meet various, somewhat arbitrary, expectations
regarding implementation choices.

What makes testability worse is any combination of too-large a
language standard ("large" being not just language features, but
excess specifications of how the language is processed) and
too many extensions.

What would make testability of gcc easier in the DWIS-like direction
you favor is to rededicate it to conform to some newly specified
model of the underlying abstract state machine and of how compilers
generate code, and permanently eliminate all optimization phases that
would violate that model.

That would make things like loop unrolling go away, of course, but
clearly, with lots less "fancy" optimization, testing gcc would
be easier.

And, for a given amount of complexity, a DWIS system is, I think,
quite a bit easier to test (and validate) than a SWYM one, indeed.
The problem for gcc is that it's SWYM+DWIS right now, every
DWIS addition makes the problem worse, not better, and it's
almost *guaranteed* we'll be making SWYM additions as well anyway.

(It occurred to me, late last night, that part of the SWYM/DWIS
conflict here is that "inline", loosely speaking, has a pretty
clear meaning for compiler *developers* that is somewhat different
than what it means to the *users* of compilers.  By "exporting" this
term to the outside world via constructs like "inline", that
conflict has been exposed.  Do the compiler developers then promise
to forever give up their ideas of what "inline" means and the
optimizations they could possibly achieve, or do their users give
up their ad-hoc ideas of what it means?  Pertinent language
standards will almost certainly evolve in the former direction,
and I expect gcc will too.)

>And yes, it's made worse by the fact that there _are_ actually sane ways
>to do _exactly_ what I want to do, but they don't work with older
>versions. People suggest I use #ifdef's etc, but that doesn't exactly
>help testability either, and makes one of the points of using inline
>functions go away completely - readability.

Right.  I think it's just a bad fit, using gcc (or almost any C
compiler) for that purpose.  I think a DWIS-like C compiler probably
exists out there, or, if not, it would be a great project to
undertake, as something using an almost entirely different code
base than gcc (though, offhand, I think it could start out sharing
the front ends, but that's about as far as it goes).

>I guess I count as a DWIS person - I think that just is what C is
>designed for.  In systems programming, you just can't let the compiler
>do too many of the decisions for you. 

Right.  C was probably viewed as DWIS by its developers early on.
Of course, the concept of SWYM was considered pretty hard to
practically implement, so in effect, *everything* was DWIS,
except some things like the early Fortran compilers and such.

>Obviously, C++ is very much a SWYM environment, and the compiler copes
>best it can.  That's one of the reasons we very quickly discarded C++ as
>a kernel language (we used to compile the Linux kernel with C++ a
>_loong_ time ago, back when people still thought OO was a sexy
>"must-have"). The compiler was just too unpredictable in many ways.

I'd say that's a pretty solid judgement, and would posit that what
you're running into is a combination of "feature creep" of SWYM-like
characteristics into the C language and especially the gcc (vs. g++)
compiler, and of optimizations (put into gcc) that rely more and more
on assuming C programmers are really SWYM'ers, not DWIS'ers.  (Actually,
you're not really running into this *yet*; I'm getting ahead of myself,
as my main concern over these posts is to help everyone understand
this problem is going to get worse, not better, in the future, though
*which* of these problems we decide to accept has yet to be determined.)

And, of course, the reason C is a bad language for DWIS'ers is that
they're not permitted to fully express their DWIS constraints (which
would amount to SWYM regarding DWIS).  `volatile' is an example
of that ability, but is nowhere near enough, and already it has
been overloaded somewhat.

It occurs to me that, in a sense, what you want in combining `extern
inline' with an address of a label is akin to making a particular
function *invocation* `volatile', and being able to report the address
of where that *invocation* occurs, in memory.  One way to look at
`volatile' in this context is, "I want to be able to tell the CPU,
which supports hardware breakpointing on a PC value, to break exactly
when it gets to this *particular* invocation as it appears in the
source code, which means there must be a one-to-one mapping between
the source-code expression of an invocation and the machine-code
invocation itself, and I must have a reliable way of extracting the
address of that invocation so I can provide it to the hardware using
some extra-linguistic method."

Not that I'm proposing this as an extension (it'd still be feature
creep), but, if you had *that* feature, in that instance, you wouldn't
really care if the function invocation itself was inlined, right?
I mean, if the compiler *knew* it'd go faster if it was inlined, or
if it wasn't, and thus actively ignored "inline", that wouldn't
bother you for the case I think I'm talking about?

Still, it's overspecified for your purposes anyway: you don't really
*need* a one-to-one mapping.  You wouldn't mind it being loop-unrolled
or similar, into multiple copies, as long as you could identify any
of *several* possible PC values as belonging to one particular
source invocation.  (Well, I'm guessing about what you need here,
which is risky.)

So, if you did use `volatile' here, you'd be constraining the compiler
to *not* produce, perhaps, more optimal code, even though it might
be able to do so and still meet your *actual* objectives, which
are not communicable in C.  For DWIS'ers, that's often acceptable,
while, for SWYM'ers, it isn't, and they tend to fight over keyword
or namespace "territory" the way people fight over `.com' addresses.

>>In the meantime, it'd be a good idea to decide which direction
>>gcc should go, which I think the industry as a whole has concluded is
>>"SWYM", since that's where C's going, and stick with it, completely,
>>or nearly, ignoring proposed extensions representing the other side,
>>because C, as a language, cannot support both paradigms (it can
>>barely support one).
>
>I would hope you don't propose to go too far. In many areas, the main
>strength of C is still as a reasonably portable low-level programming
>tool that doesn't get in your face.

Yes.  I've seen the collision coming for a *long* time now, and
I'm sure others have too.  I think the train has rolled out of
the station already, long ago, once the C language standardization
effort decided to become less DWIS-like and more SWYM-like, e.g.
by trying to "reach out" to the Fortran audience (Fortran being
*much* more SWYM like, at the lower levels, than C).

But that doesn't mean a group can't form to specify a DWIS-like
subset+extensions of C and fork off a DWIS-like implementation
of gcc.  It'd be a lot of work to do, and I'd worry about whether
they'd be going down a technological cul-de-sac, but I think the
sheer mass of need for such a thing would make that less of a
concern, perhaps less likely, especially in the context of the
C language, which will probably never offer enough SWYM-like
facilities to obviate their need for DWIS-like ones.

(I've gotten the impression that, in addition to Linux and other
OSes compiled by gcc, there are *lots* of embedded developers out
there who would prefer to use a more DWIS-like gcc.)

>For SWYM, we already have things like visual basic,

Heh, well, I don't really know that language; maybe.  I don't know
Haskell either, but I gather it's much more SWYM-like than most
anything we're discussing.  Ditto for Prolog, where the cut operator
is one of the closest things to DWIS-like behavior the original
language had.

The way I look at the evolution of the compiler "beast" over the
decades is that it started out as basically an insect-like robot --
very predictable, but not very useful, and very DWIS-like.

As it evolved, it became slowly more SWYM-like, because people wanted
to be able to say things more like "here's what I want to accomplish"
rather than "here's what you do".  Kind of like how it's sometimes
easier to get a 15-year-old to clean up his room by saying "clean up
your room", and he knows what a clean room looks like, etc., than
a 3-year-old, who doesn't know from "clean" and must therefore be
told, step by step, exactly what to do: "put this toy *there*, put
that toy up *there*".  (And, yes, the more SWYM-like entity can be
more resistant to doing things the *way* you want.  :)

At the same time, as compilers *multiplied*, more and more people
became dependent on exactly *how* they happened to do things -- i.e.,
though they were *evolving* to be more SWYM-like, these people
were relying on their *particular* copies to retain certain DWIS-like
characteristics.  Then, when they decide to upgrade, they've suddenly
got an *evolved* copy that doesn't behave they way they expect,
even though it might be behaving exactly as the developers want and
expect it to.

Here's where we are right now: gcc is kinda like the Arnold Schwarzenegger
robot in the movie Terminator.  You tell it something to do, and you
can pretty much guess how it'll do it, and be right most of the time,
so it's still fairly DWIS-like.  But it also has lots of SWYM-like
characteristics, of course -- for a sufficiently complicated task,
you *can't* predict exactly how it'll accomplish it.  You might think you
have *some* idea of how reliably you can predict some tasks, but you're
almost certainly wrong, even if you're its original programmer.  (The
Asimov series starting with "I, Robot" is, IIRC, an excellent introduction
to the sorts of problems that result from using automatons, including
assuming too much about how they will accomplish their tasks.)

So, if you've got a friend you want to intimidate and a Terminator
robot at your command, you can say "Terminator, go strangle my friend".

You *know* the robot will have to walk across the room to accomplish
this...that it'll make *lots* of noise and look *very* menacing doing
so...take a certain amount of time to do so...and that your friend
will get *real* scared.  At the last moment, you can say "Terminator,
cancel command" (or whatever), and you can all enjoy a good laugh.

But Terminator has some pretty serious limitations in terms of what
it can accomplish, and many of its users expect more of it.  In that
sense, it needs to become even more flexible -- more able to do tasks
in ways that would seem completely unpredictable.

Now, you hear about this *new* robot (in "Terminator II") and upgrade,
because you hear it'll do things faster, better, etc. than your
current robot, and you *gotta* have that, because while you love
the old robot, you've learned a lot about its limitations.

You try the same thing -- "Terminator, go strangle my friend" -- and
within about 50 milliseconds it has slithered small liquid-metallic
tendrils across the room, which crushed your friend's windpipe, all
without most of it apparently moving an inch.  Not so much laughter,
though you end up with more pizza and beer for yourself.

Now, is either robot completely SWYM?  No, nor completely DWIS.  Did
both robots do what you told them?  Yes.  Whose fault was it that
your friend got strangled?  Yours.

Why?  Because you failed to explicitly *constrain* the T2 robot to
meet your requirements -- requirements that were *implicitly* met
by the design limitations of the T1 robot, which the T2 robot neither
had, nor was designed to emulate.  You didn't say "*pretend* you're
going to strangle my friend, so he has time to see it coming and
get real scared, but don't actually do it", or something like that.

The designers of the C language, and of computer languages in general
(excluding Java, perhaps), just like the fictional designers of the
Terminator robots, know that The Future is in more SWYM-like designs.

They *also* know that, to keep complexity down, newer designs must
jettison archaic, DWIS-like constructs that existed primarily to work
around old limitations that they were superseding in the new designs
via more SWYM-like things.  (E.g. Fortran is likely to jettison COMMON,
EQUIVALENCE, and other "old favorites" someday, though it'll be some
time after before *compilers* actually do.)

So, as long as gcc is following the general path of implementing
standards like the C, C++, and Fortran languages, which are evolving,
almost exclusively, along SWYM lines, gcc will *have* to evolve, itself,
along SWYM lines.

And, to keep complexity down, it'll perhaps have to drop DWIS features,
and it certainly will have to stop accumulating new ones.  Heck,
we're *already* spending way too much time dealing with configury
issues (the Makefiles plus the configurations), largely because
make, originally intended to be SWYM-like, has accumulated features
and a culture that are too DWIS-like and thus too brittle, and because
of other DWIS-like stuff in that area (use of shell scripts, configure
scripts, etc.).  That doesn't even involve the code to do things
like read C programs, optimize them, and generate assembly, which
*should* be where we're spending the vast majority of our efforts!

As an OS developer, I've *long* appreciated the advantages of a more
DWIS-like compiler, and, in my experience, OSes are almost always
compiled by something *other* than the primary compiler being vended
for application code.  (At Prime, PRIMOS was written in assembler,
a FORTRAN-66 subset, and a small PL/1 subset called PL/P, and compiled
by the corresponding archaic compilers *long* after Prime offered
new, "better", FORTRAN 77, PL1/G, and full PL/1 compilers.  I recall
hearing that Sun used *gcc*, not its vended, unbundled compiler,
to compile either SunOS or Solaris for quite a while, though I
think they started switching away from that, last I heard around a
year ago.  Then there's BLISS at Digital, et al, but I don't have
much personal experience with these company's OS design efforts.)

So, I have *no problem* with someone meeting the need of OS developers
and embedded-software developers by providing a much more predictable
DWIS-like design.  It could even be an offshoot of gcc.

I just can't see any way gcc will be able to continue to evolve if it
takes on both roles, one SWYM-like, the other DWIS-like.  Heck,
look at the problems we're already having accommodating the two
*audiences*!  That is, there's *often* a clash here among the
SWYM-like audience that wants gcc to just "do the right thing"
to make their code faster, smaller, etc, the DWIS-like audience
that wants gcc to just do what they think they've told it to, and
the gcc developers, usually somewhere in between, who say "we're
trying to make it fast [a la SWYM] within the constraints of what
people actually expect beyond and above what the standard specifies
[a la DWIS]".

Also, I've long had high hopes that a much more comprehensive SWYM-like
language and compiler could actually *eliminate* the need for DWIS-like
tools in areas such as operating systems and embedded software,
by permitting SWYM expressions of external timing constraints,
for example.

That language won't be C, though, and probably not any other imperative
language currently fashionable (if it's even imperative at all).

Getting back to the proposal for a "force inline" directive, let me
ask a simple question, and see how you and others respond:

Would it *ever* be permissible for gcc to generate *different* code
from sources containing normal "inline", without warning at all
given `-Winline' (meaning it succeeds at all the requested inline),
as compared to the exact same sources compiled by the exact same
copy of the compiler, but with any of those normal "inline"s modified,
in the source, to be "force inline"?

In other words, does the simple act of specifying "force inline"
where "inline" used to *succeed* (as defined by `-Winline')
permit gcc to change the code it produces, perhaps radically?

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

In article < 19990212031118.4271.qmail@deer >,  <craig@jcb-sc.com> wrote:
>
>The buglet in gcc has, I gather, already been fixed.

Yes. 

The sad part is that the bug was fixed several months ago. It was just
re-introduced _again_ last week.

>						  I haven't
>gotten the impression the underlying bug(s) in Linux have, or
>will, get fixed.

Craig, have you actually bothered to look at the Linux use of "inline"
at all? I don't think you have, and you're just spouting sh*t on the
list. 

It's not at all buggy, it just assumes that the compiler does something
reasonable. 

In particular, there are two kinds of "inline" in the kernel.  There's
the "oh, I'd like to get this inlined" kind of inline, and there's the
"consider this a macro" kind of inline. 

Please go and actually look at the sources you complain about.  I'm not
an unreasonable person, I just get DAMN irritated when the same bug
shows up twice in gcc, and people have a hard time even admitting it is
a bug (I think the post by you is the first one that actually calls it a
"buglet", finally - it's a bug, and yes, it was small, but by golly it
was HARD to get people to even acknowledge it as one). 

Basically, Linux _does_ already use the "inline as hint" mentality: we
have tons of functions that are marked "static inline" or just "inline". 
Some of those functions are quite large, and some of them actually only
make sense inlining on an alpha or other sane architecture that has tons
of registers: and I'd be very happy if gcc actually decides at some
point that "oh, this function just adds too much register pressure to
make sense to inline on an x86". 

There's another class of "inline" usage, though - the "use as macro"
class, because inline functions are often a _lot_ more readable than
macros are, and you get tons of other advantages (the compiler does the
argument copy so you don't have side effect problems, and often most
importantly you get argument type-checking with good error messages with
inline functions that you wouldn't get with a macro).  Those "use as a
macro" inlines are marked, for the edification of gcc, as "extern
inline". 

Guess what? A lot of them _used_ to be "static inline", because "static
inline" is safer (it works as expected in the presense of the address-of
operator, and yes, if the compiler refuses to inline the thing because
it's not optimizing, it will still create the function for you).  Most
of them were _changed_ to "extern inline" mostly due to the gcc
documentation.

So Craig, go and look at some of those "extern inline" functions. 
Instead of just spouting crap on the mailing list without obvously never
having even _looked_ at the problem.  All of them are _extremely_
reasonable as far as I can tell - feel free to look for yourself.

The ones that were bitten by the egcs bug (let's just be honest and call
it what it really was) were so small that it would have been completely
unreasonable for any good compiler to not inline them.  They were
essentially two assignments and a copy, they just happened to have the
address-of-label thing in some debugging code (because all other gcc
methods of getting the current PC have been buggy at various points). 

Basically, Craig, just come down from your ivory tower and look at the
code, and I'd be surprised if you didn't agree with me that Linux
"extern inline" usage actually makes sense if you were to just spend a
_small_ amount of time actually looking at it instead of spouting off
without knowing what's up.

		Linus

Re: kernel-2.2.1-undefined references.

[Bryan W. Headley]

Mike Stump wrote:

> > From: "H. Peter Anvin" <hpa@transmeta.com>
> > To: jbuck@Synopsys.COM (Joe Buck)
> > Date: Mon, 8 Feb 1999 11:09:32 -0800 (PST)
>
> > However, I think the right thing to do is to force an inline and if
> > it is impossible, document when it's impossible, and give an error.
>
> I don't agree.  We expect you to support your request in a compelling
> way.  I haven't seen anything compelling yet.  I think there is a real
> bug that needs to be fixed, on this we can agree, but when this bug is
> fixed, what is the difference between register and inline?  Look were
> register is today, totally ignored and totally meaningless.  inline is
> becoming much the same sort of thing, and we don't give hard errors if
> register fails, never have never will.  For consistency, inline should
> behave in a similar fashion.

Mike,

It all depends on whether you are making an application compiler or a
platform-independent assembler, which C originally was. If I wrote some
code where I expect measurable time rolling and unrolling a stack frame
going into a function, and it's not there because of an auto-inline
optimization, I'd be screaming. 'volatile' functions are too weird at
this late date.

This takes me back to the original arguments against C++, where you know
what you've written, but you're not sure how the compiler opted to
generate the code. A runtime environment where exception-handling guts
can't be easily guessed at. Of course if you've Stan Lippman's compiler
internals book, you'd know what cfront would do.

Having been moved into a java-like, you-guess-what-it's-doing
environment, I feel like writing a java assembler :-)

--
____               .:.                 ____
Bryan W. Headley - bheadley@interaccess.com

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> That's fine. I'm actually not asking that _all_ "inline" keywords actually
> be honoured, I'm asking that there be some way of forcing gcc to honour
> it, the way it used to do. 

You are still making one incorrect assumption: that you previously had
a guarantee that the compiler would always successfully inline an "extern
inline" function.  You didn't: any version of gcc you care to name would
fail to inline some functions.

> Codifying the fact that if you really _rely_ on inlines, do so with an
> "extern inline" is ok would be very reasonable. Maybe you could even say
> that "extern inline" is honoured even when not optimizing.

Given the current state of things, extern inline could either inline the
function or "die trying".   However, once some standards document says
extern inline means something different, someone will have to suffer:
either every C user (can't give them a correct compiler), or the kernel
developers (we'll have to tell them a new way of forcing "inline").

> Why not just say that for "extern inline" there are NO artifical limits,
> because the damn documentation _tells_ you that "extern inline" is a gcc
> extension to the language that creates a macro-like function. 

Why not just say that the Linux kernel fits in 1 Meg no matter how many
devices or features you have?  After all, it used to.  It would be nice.

The compiler can do its best to inline the function.  But it cannot
promise to do the impossible.

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> Be aware that __builtin_return_address probably will stop working
> someday in gcc.  Read my latest tirade to get an idea of why that is.

Craig, gcc is the GNU project's compiler.  That means that one of its
important roles is to be able to compile kernels (Linux or the Hurd).
Since you're the Fortran guy, you are somewhat insulated from these
issues (Fortran just doesn't make provisions for writing "close to the
machine" code).

The result is that gcc is going to have to continue to support certain
extensions for the indefinite future (though kernel developers should
not assume that "it worked in version x.y.z" is a commitment for the
future, we will need to supply some mechanisms in some cases.

It may actually be easier to support features like this if they are
specified at a higher level of abstraction.  That is, understand why Linus
is using some trick to do something, and then recommend alternative ways
to do them that are actually supportable.  e.g. if the real job is to get
a stack trace, maybe there could be some facility to provide for that
directly, possibly borrowing some code from gdb.

Despite Linus's tendency to be insulting, he is one our most important
"customers" (or, more accurately, the people who depend on the Linux
kernel working are).  We need to have sufficient facilities so that C plus
inline assembly can do the whole job.

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

Christ Craig, give it a rest. This is a dead horse you're beating. Some
reasonable sane and rational suggestions for solving the problems both with
Linux and egcs have appeared; someone's found that a conditional compile
can be used to make the extern inline thing compile and work on every gcc
by either using __builtin_return_address or the label hack; Linus has said
the panic code isn't too critical anyways and has apologized for some of
the tirades earlier in the week; and it seems to be high time this issue
was let drop on the list; yet I keep seeing more tirades from you every few
minutes to an hour.

BTW, did you know that your ISP's mail server was bouncing mail
inexplicably all afternoon? Was bouncing messages with "Service
unavailable". Never heard of downtime causing mail to bounce before;
usually it's deferred. You should have a few stern words with your ISP's
customer service reps about this; if the downtime had been much longer the
bounces would have caused yo to be removed from this list and any others
you're on more than likely. They should just defer the mail.


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Jamie Lokier]

H. Peter Anvin wrote:
> Oh yes, __builtin_constant_p() really, really ought to work properly
> in an inline...

It does.  See egcs-1.0.3.

-- Jamie

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> From: "H. Peter Anvin" <hpa@transmeta.com>
> To: jbuck@Synopsys.COM (Joe Buck)
> Date: Mon, 8 Feb 1999 11:09:32 -0800 (PST)

> However, I think the right thing to do is to force an inline and if
> it is impossible, document when it's impossible, and give an error.

I don't agree.  We expect you to support your request in a compelling
way.  I haven't seen anything compelling yet.  I think there is a real
bug that needs to be fixed, on this we can agree, but when this bug is
fixed, what is the difference between register and inline?  Look were
register is today, totally ignored and totally meaningless.  inline is
becoming much the same sort of thing, and we don't give hard errors if
register fails, never have never will.  For consistency, inline should
behave in a similar fashion.

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Wed, 10 Feb 1999, Marc Espie wrote:
>
> You could *at least* acknowledge that you read the original documentation 
> wrong, and that you relied on your interpretation of it...

Would that make you happier?

Yes, I publicly acknowledge that the documentation did not _guarantee_
that "inline" will inline. I've several times mentioned that it makes
perfect sense to not inline in many cases.

My gripe is (and has been) that somebody changed gcc behaviour for no good
reason, and that the behaviour was strongly implied in the documentation. 
Furthermore, all features involved were documented gcc extensions, and
that the Linux usage was in no way unreasonable. The functions in question
were

 (a) very small
 (b) _needed_ to be inlined exactly because they used another gcc feature
     in order to report potential problem locations correctly.
 (c) did not do _anything_ that could reasonably be considered illegal in
     an inline function.

And yes all of it could have been done some other way. The reason Linux
used them as it used them was that all the other portable alternatives
were more broken (I'd have _loved_ to use documented gcc interfaces, but
they didn't actually happen to work). 

And no, very few others are complaining, because the breakage only
happened when you used two gcc extensions together ("inline" and address
of a label). Linux is probably the only thing that actually uses a lot of
the extensions. 

			Linus

Re: kernel-2.2.1-undefined references.

[Jeffrey A Law]

  In message < 7a2691$cf9$1@palladium.transmeta.com >you write:
  > In article < 9211.918849009@hurl.cygnus.com >,
  > Jeffrey A Law  <law@hurl.cygnus.com> wrote:
  > >
  > >  In message < 7a203j$9cf$1@palladium.transmeta.com >you write:
  > >  > 
  > >  > The sad part is that the bug was fixed several months ago. It was just
  > >  > re-introduced _again_ last week.
  > >
  > >No.  This is not what happened.  Please don't state this as a fact since y
  > ou
  > >do not know the facts.  If you would like to know the facts, then ask.
  > 
  > I was _there_, Jeff. The bug got introduced in the gcc-2.8.x development
  > tree,
Yes.

  > and we had this same discussion - it just happened to be more
  > private.
We were discussing how to deal with the problem in egcs when we sucked in that
code.  Not what to do with gcc2.

  > The bug was fixed back then by Richard Henderson, he just
  > didn't get permission to check in his fix.
He had permission to check in the fix to the egcs tree when we sucked in the
offending gcc2 code.  You can't blame rth or the egcs project for the inability
to get a change into the gcc2 tree as we have zero control over what goes into
that tree.

  > The bug then re-appeared in egcs apparently simply due to a merge with
  > gcc-2.8.x, exactly because rth hadn't gotten his fix in originally.
Not exactly.  Again, rth had permission to fix this problem when it came into
our tree due to the merge.  And that is precisely what happened.

Get your facts straight please.

jeff

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 10:12 PM 2/14/99 -0500, you wrote:
>I don't think so. How the hell else can you write C code that works with
>data that changes asynchronously, e.g. because of multiple threads or
>because of hardware or interrupts or signal handlers or...

By the way, don't say use mutexes and semaphores.
1. Hardware doesn't understand these things, and you do need software
   to interface to hardware.
2. A modal signal/exception handler would be in deep trouble if it
   encountered a mutex that was locked and decided to wait for it to
   unlock...and wait, and wait, and wait...
3. The semaphores and mutexes need to be coded as well. They need
   state variables, and those state variables need to be modified
   asynchronously, *without* using a mutex or semaphore as this would
   be a chicken and egg problem! So the mutex flag or semaphore
   counter needs to be 'volatile', so code like this:

   void mutex::get_lock (void) throw () {
     suspend_task_switching();
     while (locked) {
       resume_task_switching();
       yield();
       suspend_task_switching();
     }
     locked=true;
     resume_task_switching();
   }

   doesn't hang in an infinite loop because 'locked' was optimized
   into a register and the while loop therefore never exits since its
   register copy of 'locked' never changes! So we need

 private:
   volatile bool locked;

   or the mutex class won't work worth a damn.

     
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Jamie Lokier]

Jamie Lokier wrote:
> H. Peter Anvin wrote:
> > Oh yes, __builtin_constant_p() really, really ought to work properly
> > in an inline...
> 
> It does.  See egcs-1.0.3.

Bugger, I was wrong.  Sorry Peter.

I was _told_ it is working in some EGCS version, and misread a test I
did earlier.  It ought to be working by now: I submitted a patch a very
long time ago, and was told something similar had been installed into
the tree.

-- Jamie

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

In message < 003c01be53b6$5b04ff40$a8a11dcb@animal.ihug.co.nz > you write:
> From: Per Bothner <bothner@cygnus.com>
> >
> >[Linus wrote:]
> >> I'm not trying to be unreasonable. I'm just saying that if there is a
> >> function that is marked inline that can be inlined, it _should_ be
> >> inlined, because the compiler _never_ knows better than the programmer.
> >
> >Er, the compiler often knows better than the programmer.  That is why
> >we use compilers - to free us from low-level and architecture-dependent
> >decisions.
> >
> >We cannot design a compiler for the Linux Torvalds' of the world.
> >We have to do what is best for *most* programmers, while still
> >providing the needed tools for the experts.
> 
> It occurs to me that the real problem here is that "inline" is being
> used to refer to two slightly different concepts, and some of the
> participants in this thread haven't noticed this and are talking past
> each other.
> 
>   (A) inline == "I [the programmer] know exactly what this code is
>   supposed to do at low level, and I have determined that this function
>   must be inline for proper behaviour, so inline it or give me an error
>   if you [the compiler] can't."

It occurs to me that we do, in fact have an acceptable method of
*guaranteeing* inlining of a *function* in gcc.  That is a combination
of a macro and the "Statement Expression" extension.

#define foo(_x) ({				\
  int x = (_x);					\
  /* Various commands */			\
  val;						\
)}

is *already* the exact equivalent of:

extern inline foo (int x) {
  /* Various commands */
  return val;
)  

except that it also says, "I know exactly what I'm doing and this function
*must* be inlined".  Surely the number of functions in the kernel
which *must* be inlined for correct functioning is small
transformation can be done and ensure that correct code is generated.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Alan Cox]

> "correct" way to do it. (Famous last words, I know. On the other hand,
> neither 'side' of this debate needs the ego boost provided by Having Been
> Right All Along, so...)

Well its really a 2.3 issue in my book. We tied 2.0 to a compiler and its
proved the right choice. Playing games with sensitive inline code during 2.2
doesnt appeal to me at all

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 10:12 PM 2/14/99 -0500, you wrote:
>I don't think so. How the hell else can you write C code that works with
>data that changes asynchronously, e.g. because of multiple threads or
>because of hardware or interrupts or signal handlers or...

By the way, don't say use mutexes and semaphores.
1. Hardware doesn't understand these things, and you do need software
   to interface to hardware.
2. A modal signal/exception handler would be in deep trouble if it
   encountered a mutex that was locked and decided to wait for it to
   unlock...and wait, and wait, and wait...
3. The semaphores and mutexes need to be coded as well. They need
   state variables, and those state variables need to be modified
   asynchronously, *without* using a mutex or semaphore as this would
   be a chicken and egg problem! So the mutex flag or semaphore
   counter needs to be 'volatile', so code like this:

   void mutex::get_lock (void) throw () {
     suspend_task_switching();
     while (locked) {
       resume_task_switching();
       yield();
       suspend_task_switching();
     }
     locked=true;
     resume_task_switching();
   }

   doesn't hang in an infinite loop because 'locked' was optimized
   into a register and the while loop therefore never exits since its
   register copy of 'locked' never changes! So we need

 private:
   volatile bool locked;

   or the mutex class won't work worth a damn.

     
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

>Read archives of comp.compilers and related works if you really
>want to learn why "C is closer to the machine than Fortran" is,
>for all intents and purposes, something between a myth and a self-
>fulfilling prophecy.  And why "volatile" is a great example of a
>supposedly necessary feature that, linguistically speaking, makes
>almost every computer language that incorporates it *worse* than
>it would be without it.

I don't think so. How the hell else can you write C code that works with
data that changes asynchronously, e.g. because of multiple threads or
because of hardware or interrupts or signal handlers or...

The choices are:

1. Don't optimize at all -- UNACCEPTABLE
2. Mark data the compiler isn't to optimize into registers and about
   which it isn't to make any assumptions regarding the value being
   consistent.

The latter gets us 'volatile'.

Which do you choose?

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> Read archives of comp.compilers and related works if you really
> want to learn why "C is closer to the machine than Fortran" is,
> for all intents and purposes, something between a myth and a self-
> fulfilling prophecy.

Of course it is a "self-fulfilling prophecy" -- given that a major use of
C is in embedded systems, the customer base believes that C (rather, at
least some C constructs) is "close to the machine" and will demand the
ability to do things like write code that interacts with memory-mapped
hardware in C, and compiler vendors will respond to this demand (in
practice, C++ is just as "close to the machine" in this sense as C).  It
appears that you don't like this, and I know that many of the academics
that hang out on comp.compilers object to it (but then, they don't like C
-- some of their reasons are valid, some are merely prejudices).  But
these are only opinions.

And please drop phrases like "if you really want to learn" ... I have
extensive experience with the issues involved.

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 04:25 PM 2/14/99 PST, you wrote:

>You are incorrect, I'm afraid.  What Fortran construct corresponds
>to "volatile", which is in essence a model for a memory-mapped device
>register?

Or a variable that may be modified asynchronously by software, e.g. a
hardware interrupt, a signal handler, multiple threads in a multithreaded
program...

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[craig]

>> And, note, C doesn't really make provisions for writing "close to the
>> machine" code any better than Fortran.
>
>You are incorrect, I'm afraid.  What Fortran construct corresponds
>to "volatile", which is in essence a model for a memory-mapped device
>register?

I stand by my original statement -- including the part you didn't
quote in my email about "volatile" -- but I'm not about to argue this
anymore.

Read archives of comp.compilers and related works if you really
want to learn why "C is closer to the machine than Fortran" is,
for all intents and purposes, something between a myth and a self-
fulfilling prophecy.  And why "volatile" is a great example of a
supposedly necessary feature that, linguistically speaking, makes
almost every computer language that incorporates it *worse* than
it would be without it.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> And, note, C doesn't really make provisions for writing "close to the
> machine" code any better than Fortran.

You are incorrect, I'm afraid.  What Fortran construct corresponds
to "volatile", which is in essence a model for a memory-mapped device
register?

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 03:24 PM 2/13/99 -0000, you wrote:
>Do you have any bounced email to forward along, so I can see what
>was actually happening?  That's the first thing my ISP would
>ask for, probably.

Yeah. Here. (Apologies to list, but since Craig's mail server is still
bouncing mail intermittently...)

I already tried sending this to postmaster@jcb-sc.com, and got the same
sort of bounce. I did Whois lookup and saw their technical and admin
contacts at world.std.com; I mailed them suggesting they fire the
postmaster and noc at jcb-sc.com and telling them why, and world.std.com
bounced as well. Is damned weird.

At least if you suddenly find that your subscription to egcs lists has
evaporated, you'll know why (your server started bouncing incoming mail
again and triggered the automatic bad-address-unsubscribe) and who to blame
(your ISP).


>The original message was received at Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>from dialin109.ottawa.globalserve.net [207.176.153.109]
>
>   ----- The following addresses had permanent fatal errors -----
><craig@jcb-sc.com>
>
>   ----- Transcript of session follows -----
>... while talking to world.std.com.:
>>>> MAIL From:<pderbysh@usa.net>
><<< 550 Wrong.
>554 <craig@jcb-sc.com>... Service unavailable
>Reporting-MTA: dns; smtp2.globalserve.net
>Received-From-MTA: DNS; dialin109.ottawa.globalserve.net
>Arrival-Date: Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>
>Final-Recipient: RFC822; craig@jcb-sc.com
>Action: failed
>Status: 5.0.0
>Remote-MTA: DNS; world.std.com
>Diagnostic-Code: SMTP; 550 Wrong.
>Last-Attempt-Date: Fri, 12 Feb 1999 19:02:40 -0500 (EST)
>Return-Path: <pderbysh@usa.net>
>Received: from chaoszone (dialin109.ottawa.globalserve.net [207.176.153.109])
>	by smtp2.globalserve.net (8.9.1/8.9.1) with SMTP id TAA19254;
>	Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>Message-Id: < 3.0.6.32.19990212190141.00891c70@pop.netaddress.com >
>X-Sender: pderbysh@pop.netaddress.com
>X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
>Date: Fri, 12 Feb 1999 19:01:41 -0500
>To: craig@jcb-sc.com
>From: Paul Derbyshire <pderbysh@usa.net>
>Subject: Enough is enough... truce time. Re: kernel blah blah blah
>Cc: egcs@egcs.cygnus.com
>In-Reply-To: < 19990212221225.22651.qmail@deer >
>References: < 7a203j$9cf$1@palladium.transmeta.com >
> < Pine.LNX.3.95.990209135218.2116D-100000@penguin.transmeta.com >
> < 19990211201836.2781.qmail@deer >
> < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
> < 19990212031118.4271.qmail@deer >
> < 7a203j$9cf$1@palladium.transmeta.com >
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>
>Ohh....my...GOD.
>
>*referee whistle blowing sound*
>
>HEY. Lets have a truce here... no more mudslinging and general aggravated
>shouting. I'd think that's beneath the station of the likes of Linus
>Torvalds and the GCC/EGCS development gurus.
>
>In "A Final Solution." I suggested some ways to change the compiler or
>Linux or both to meet everyone's needs and leave everyone happy.
>
>As for who's wrong, I don't think anyone is. There has been a
>*misunderstanding* about the ambiguous phrase "like a macro" in the
>documentation. Some took this fairly literally regarding faithfulness of it
>being expanded inline; others took it to mean "like a macro when it is
>inlinable". Chalk it up to ambiguous documentation, and let's bury the
>hatchet. And to reiterate, there are 3 things that can be done.
>
>1. Make the dox clearer about "extern inline".
>2. Linus, if worse comes to worst, you may just have to replace one-
>   off inlines with macros, or at least use -Winline and jiggle it
>   until it inlines. This strikes me as rather unsatisfactory
>   however.
>3. EGCS developers, if "extern inline" can't be and wasn't meant to
>   be what Linus had in mind after reading the dox for it, I suggest
>   adding an __attribute__ ((always)) that causes an error if the
>   function is not inlinable or a label address from a label inside
>   the function is used outside it and an __attribute__ ((once)) that
>   inlines a function where it's used, making an error if it's used
>   more than once; this means that the compiler can inline the
>   functions with these attributes without any worry that it will
>   lead to ambiguous references to addressed labels.
>
>-- 
>   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
>-()  <  circles, and bark is not smooth, nor does lightning travel in a
>   `*'  straight line."    -------------------------------------------------
>        -- B. Mandelbrot  | http://surf.to/pgd.net
>_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
>Programmer & Humanist|ICQ: 10423848|
>


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[craig]

>> Be aware that __builtin_return_address probably will stop working
>> someday in gcc.  Read my latest tirade to get an idea of why that is.
>
>Craig, gcc is the GNU project's compiler.  That means that one of its
>important roles is to be able to compile kernels (Linux or the Hurd).
>Since you're the Fortran guy, you are somewhat insulated from these
>issues (Fortran just doesn't make provisions for writing "close to the
>machine" code).

Actually, I'm not talking as the "Fortran guy".  I'm talking as someone
who understands operating systems development and computer-architecture
issues better than he understands Fortran compiler development.

And, note, C doesn't really make provisions for writing "close to the
machine" code any better than Fortran.  It provides a *model* that
more closely parallels many of today's most popular architectures,
making it more "obvious" to today's programmers that a straightforward
translation is possible, but *nothing* in the C standard, aside
from stuff like `volatile' (assuming that's even in the standard),
says anything about the mapping to the underlying machine.  But the
"as if" rule means you can't just *assume* the machine will behave
a certain way when running C code.

(I've worked on operating systems written in Fortran, assembler, and
PL/1, but no C, by the way.)

I've written on this range of topics, especially involving C, C++,
Fortran, and operators, on USENET many times in the past, so I don't
think it behooves anyone to go into more details.  I'll just disagree
with the assertion and leave it at that, noting that the way Fortran
offers similar *effects* as almost all of C's facilities does, usually,
require somewhat more typing.  :)

>The result is that gcc is going to have to continue to support certain
>extensions for the indefinite future (though kernel developers should
>not assume that "it worked in version x.y.z" is a commitment for the
>future, we will need to supply some mechanisms in some cases.

Oh, I agree.  I'm not saying that feature *will* stop working, just
that, at some point in the future, when gcc is *expected* to support
high-performance platforms like massively parallel machines, it will
either have to stop returning anything other than 0 from that
function in many cases, or the mere use of that function will
mandate a substantial drop in performance of the compiled code,
if my guesses about future directions of computing are correct (and
they're hardly controversial).

If that substantial drop happens, the users who notice it will
complain saying "it stopped working", is my prediction.

>It may actually be easier to support features like this if they are
>specified at a higher level of abstraction.  That is, understand why Linus
>is using some trick to do something, and then recommend alternative ways
>to do them that are actually supportable.  e.g. if the real job is to get
>a stack trace, maybe there could be some facility to provide for that
>directly, possibly borrowing some code from gdb.

Exactly.  Doing that is pretty hard, but I think it's better to try
and do it up front, offer the most SWYM-like ways for people like
Linus to express themselves, and support *that* as well as possible.

(After all, what the heck *is* a "stack trace", precisely defined,
and exactly how does "getting" it help Linux developers?  As soon
as you start answering by talking about frame and stack pointers,
you've headed off the SWYM reservation and are assuming a particular
machine model for gcc to permanently cater to, at the expense of
more powerful machines that don't fit that model.)

Instead, for the time being, practical concerns dictate (or have
dictated) offering fairly straightforward hooks of the DWIS variety,
which tend to mandate some kind of common machine model which,
though ill-defined, matches most or all of today's targets, but
which won't necessarily match some of tomorrow's.

If and when that happens, the old DWIS constructs must, for the
new, different models, either be dropped (rendered innocuous,
whatever), or implemented such that their mere presence shuts
down lots of important optimizations.

>Despite Linus's tendency to be insulting, he is one our most important
>"customers" (or, more accurately, the people who depend on the Linux
>kernel working are).  We need to have sufficient facilities so that C plus
>inline assembly can do the whole job.

That's a highly worthy goal.  Do you think gcc's important customers
also include all those people who just write straightforward,
standard-conforming code and want it to go as fast as possible on
the most powerful machines available at the time?  I do, and these
customers basically rely on the SWYM aspects of code generation for
gcc's family of languages.

Do you think gcc can evolve to handle both those kinds of customers
and the Linux kind, which expects all the existing DWIS-like hooks
(which assume a certain static machine model) to continue working
forever, without becoming unmaintainable?  I don't.

In any case, do you think it'll be *easier* or *harder* to maintain
gcc if products like Linux are encouraged to slowly dispense with
dependencies on gcc's current DWIS-like extensions, so both Linux
and gcc are less dependent on assuming a certain static machine
model that has informed the development and use of so many of gcc's
extensions?

I think it'd be *easier*, and the sooner it's done, the better.

Finally, I'll ask a different version of the same question I posed
earlier:

Will it ever be acceptable for any version of gcc to generate substantially
different code for an application due to the addition of a single
reference to a function like `__builtin_return_address', making for
possibly *large* differences in performance between the two versions,
and perhaps in the reproducibility of bugs in the code, due to
all sorts of code and data being moved around?

        tq vm, (burley)

P.S. It's unclear to me whether C will survive long enough to make
any of the issues I raise above matter.  That is, if we can predict
its "death", meaning the point at which improving it further becomes
a non-issue for the industry, then perhaps we can also predict the
final sorts of uses to which it'll be put.  There's reasons to believe
those uses will be much more DWIS-like than SWYM-like, and others
reasons to believe the other way.  I lean towards the former, which
is why I don't get excited about the SWYM features C9X or whoever
are adding to the language: I think they'll hasten, not delay, the
death of C, because they'll just keep making a hard language harder
to use, which is death for SWYM purposes.

Anyway, once the industry decides C will finally become a DWIS-like
language for sure (let's say), then its "body of development" will
become like a corpse -- anyone who wants to pick at it, by adding
the DWIS features they need at the moment, will feel comfortable
doing so.  They'll know they aren't coding for the distant future.
gcc can then support whatever DWIS extensions it wants at that point.

But the same issues persist for other gcc languages, though I think
C++ will die before C does, because they include Fortran, Java,
Ada, and so on.

So the gcc *back end* will have to support *all* of these combinations
of SWYM and DWIS extensions, and still meet all the expectations placed
on it to generate great code for every machine imaginable.

I think that might become extremely hard to manage someday, and the
symptoms will probably be a serious development split when it comes
to supporting some new, weird, high-performance machine, for which
many of the DWIS extensions make little or no sense.

But I could be wrong, and wouldn't mind being proven so: if gcc could
literally become the world's catch-all code generator, beautifully
optimizing clean code targeting every machine, including the bizarre
ones, while also accommodating the needs of people who want to micro-
manage its code generation, that'd be *great*.

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> Be aware that __builtin_return_address probably will stop working
> someday in gcc.  Read my latest tirade to get an idea of why that is.

Craig, gcc is the GNU project's compiler.  That means that one of its
important roles is to be able to compile kernels (Linux or the Hurd).
Since you're the Fortran guy, you are somewhat insulated from these
issues (Fortran just doesn't make provisions for writing "close to the
machine" code).

The result is that gcc is going to have to continue to support certain
extensions for the indefinite future (though kernel developers should
not assume that "it worked in version x.y.z" is a commitment for the
future, we will need to supply some mechanisms in some cases.

It may actually be easier to support features like this if they are
specified at a higher level of abstraction.  That is, understand why Linus
is using some trick to do something, and then recommend alternative ways
to do them that are actually supportable.  e.g. if the real job is to get
a stack trace, maybe there could be some facility to provide for that
directly, possibly borrowing some code from gdb.

Despite Linus's tendency to be insulting, he is one our most important
"customers" (or, more accurately, the people who depend on the Linux
kernel working are).  We need to have sufficient facilities so that C plus
inline assembly can do the whole job.

Re: kernel-2.2.1-undefined references.

[craig]

[People tired of my explanations can skip to the bottom for a question
that is actually *pertinent* to the underlying issue.  And, no, this
issue has not been "solved" per se, though some of the specifics have
been, for the time being, I gather.  Search for "Getting back".]

>Indeed. Right now, to me, it seems like there is _no_ sane way to do
>what I want to do, and rely on what gcc will actually do. This is the
>result of having a bad definition of what things do.

Well...I look at it as the result of having a product (gcc) that
is trying to serve one kind of need and thus isn't really a good
fit for other kinds of needs.

>This is why I objected to the early suggestion to just make the
>documentation even more uncertain on exactly what "inline" did.  I think
>the problem in the first place was documentation that said "almost" and
>"mostly" and "maybe" and "in a blue moon". 

It should have been, and will become, even more vague, and intentionally
so.  The "as if" rule should be more clearly alluded to in the gcc
docs; meanwhile, programmers reading docs about extensions to any
compilers should *assume* the "as if" rule still applies (in the sense
that it applies to the underlying standardized language) unless clearly
documented otherwise.

At least, I think this is the direction the gcc developers would choose
to go, as it avoids the problems resulting from gcc overcommitting
to a particular implementation of "inline" that will be clearly
suboptimal someday, speaking from a SWYM perspective.

>When you have documentation like that, you can't but rely on
>implementation, because the documentation doesn't actually give you
>anything to depend on.  And then we end up in a situation where people
>like me depend on implementation and implementors point fingers at bad
>documentation. 

The idea is to not rely on particular implementations compilers choose
*at all*, or, if you must for some extra-linguistic reason, you have
to take on all the responsibilities that entails.  In other words,
if the compiler developers have not *guaranteed* you a particular
behavior given a particular combination of language constructs, now
and forever, don't rely on it, or, if you do, plan for the day when
it stops working as you expect.

I'm not saying that's easy.  :)

>Testability goes to hell too. 

Um...no, it's actually much easier in the end, because the compiler
is considered to "work" as long as it meets the specifications for
the language (which equals standard + specified extensions), rather
than do that *plus* meet various, somewhat arbitrary, expectations
regarding implementation choices.

What makes testability worse is any combination of too-large a
language standard ("large" being not just language features, but
excess specifications of how the language is processed) and
too many extensions.

What would make testability of gcc easier in the DWIS-like direction
you favor is to rededicate it to conform to some newly specified
model of the underlying abstract state machine and of how compilers
generate code, and permanently eliminate all optimization phases that
would violate that model.

That would make things like loop unrolling go away, of course, but
clearly, with lots less "fancy" optimization, testing gcc would
be easier.

And, for a given amount of complexity, a DWIS system is, I think,
quite a bit easier to test (and validate) than a SWYM one, indeed.
The problem for gcc is that it's SWYM+DWIS right now, every
DWIS addition makes the problem worse, not better, and it's
almost *guaranteed* we'll be making SWYM additions as well anyway.

(It occurred to me, late last night, that part of the SWYM/DWIS
conflict here is that "inline", loosely speaking, has a pretty
clear meaning for compiler *developers* that is somewhat different
than what it means to the *users* of compilers.  By "exporting" this
term to the outside world via constructs like "inline", that
conflict has been exposed.  Do the compiler developers then promise
to forever give up their ideas of what "inline" means and the
optimizations they could possibly achieve, or do their users give
up their ad-hoc ideas of what it means?  Pertinent language
standards will almost certainly evolve in the former direction,
and I expect gcc will too.)

>And yes, it's made worse by the fact that there _are_ actually sane ways
>to do _exactly_ what I want to do, but they don't work with older
>versions. People suggest I use #ifdef's etc, but that doesn't exactly
>help testability either, and makes one of the points of using inline
>functions go away completely - readability.

Right.  I think it's just a bad fit, using gcc (or almost any C
compiler) for that purpose.  I think a DWIS-like C compiler probably
exists out there, or, if not, it would be a great project to
undertake, as something using an almost entirely different code
base than gcc (though, offhand, I think it could start out sharing
the front ends, but that's about as far as it goes).

>I guess I count as a DWIS person - I think that just is what C is
>designed for.  In systems programming, you just can't let the compiler
>do too many of the decisions for you. 

Right.  C was probably viewed as DWIS by its developers early on.
Of course, the concept of SWYM was considered pretty hard to
practically implement, so in effect, *everything* was DWIS,
except some things like the early Fortran compilers and such.

>Obviously, C++ is very much a SWYM environment, and the compiler copes
>best it can.  That's one of the reasons we very quickly discarded C++ as
>a kernel language (we used to compile the Linux kernel with C++ a
>_loong_ time ago, back when people still thought OO was a sexy
>"must-have"). The compiler was just too unpredictable in many ways.

I'd say that's a pretty solid judgement, and would posit that what
you're running into is a combination of "feature creep" of SWYM-like
characteristics into the C language and especially the gcc (vs. g++)
compiler, and of optimizations (put into gcc) that rely more and more
on assuming C programmers are really SWYM'ers, not DWIS'ers.  (Actually,
you're not really running into this *yet*; I'm getting ahead of myself,
as my main concern over these posts is to help everyone understand
this problem is going to get worse, not better, in the future, though
*which* of these problems we decide to accept has yet to be determined.)

And, of course, the reason C is a bad language for DWIS'ers is that
they're not permitted to fully express their DWIS constraints (which
would amount to SWYM regarding DWIS).  `volatile' is an example
of that ability, but is nowhere near enough, and already it has
been overloaded somewhat.

It occurs to me that, in a sense, what you want in combining `extern
inline' with an address of a label is akin to making a particular
function *invocation* `volatile', and being able to report the address
of where that *invocation* occurs, in memory.  One way to look at
`volatile' in this context is, "I want to be able to tell the CPU,
which supports hardware breakpointing on a PC value, to break exactly
when it gets to this *particular* invocation as it appears in the
source code, which means there must be a one-to-one mapping between
the source-code expression of an invocation and the machine-code
invocation itself, and I must have a reliable way of extracting the
address of that invocation so I can provide it to the hardware using
some extra-linguistic method."

Not that I'm proposing this as an extension (it'd still be feature
creep), but, if you had *that* feature, in that instance, you wouldn't
really care if the function invocation itself was inlined, right?
I mean, if the compiler *knew* it'd go faster if it was inlined, or
if it wasn't, and thus actively ignored "inline", that wouldn't
bother you for the case I think I'm talking about?

Still, it's overspecified for your purposes anyway: you don't really
*need* a one-to-one mapping.  You wouldn't mind it being loop-unrolled
or similar, into multiple copies, as long as you could identify any
of *several* possible PC values as belonging to one particular
source invocation.  (Well, I'm guessing about what you need here,
which is risky.)

So, if you did use `volatile' here, you'd be constraining the compiler
to *not* produce, perhaps, more optimal code, even though it might
be able to do so and still meet your *actual* objectives, which
are not communicable in C.  For DWIS'ers, that's often acceptable,
while, for SWYM'ers, it isn't, and they tend to fight over keyword
or namespace "territory" the way people fight over `.com' addresses.

>>In the meantime, it'd be a good idea to decide which direction
>>gcc should go, which I think the industry as a whole has concluded is
>>"SWYM", since that's where C's going, and stick with it, completely,
>>or nearly, ignoring proposed extensions representing the other side,
>>because C, as a language, cannot support both paradigms (it can
>>barely support one).
>
>I would hope you don't propose to go too far. In many areas, the main
>strength of C is still as a reasonably portable low-level programming
>tool that doesn't get in your face.

Yes.  I've seen the collision coming for a *long* time now, and
I'm sure others have too.  I think the train has rolled out of
the station already, long ago, once the C language standardization
effort decided to become less DWIS-like and more SWYM-like, e.g.
by trying to "reach out" to the Fortran audience (Fortran being
*much* more SWYM like, at the lower levels, than C).

But that doesn't mean a group can't form to specify a DWIS-like
subset+extensions of C and fork off a DWIS-like implementation
of gcc.  It'd be a lot of work to do, and I'd worry about whether
they'd be going down a technological cul-de-sac, but I think the
sheer mass of need for such a thing would make that less of a
concern, perhaps less likely, especially in the context of the
C language, which will probably never offer enough SWYM-like
facilities to obviate their need for DWIS-like ones.

(I've gotten the impression that, in addition to Linux and other
OSes compiled by gcc, there are *lots* of embedded developers out
there who would prefer to use a more DWIS-like gcc.)

>For SWYM, we already have things like visual basic,

Heh, well, I don't really know that language; maybe.  I don't know
Haskell either, but I gather it's much more SWYM-like than most
anything we're discussing.  Ditto for Prolog, where the cut operator
is one of the closest things to DWIS-like behavior the original
language had.

The way I look at the evolution of the compiler "beast" over the
decades is that it started out as basically an insect-like robot --
very predictable, but not very useful, and very DWIS-like.

As it evolved, it became slowly more SWYM-like, because people wanted
to be able to say things more like "here's what I want to accomplish"
rather than "here's what you do".  Kind of like how it's sometimes
easier to get a 15-year-old to clean up his room by saying "clean up
your room", and he knows what a clean room looks like, etc., than
a 3-year-old, who doesn't know from "clean" and must therefore be
told, step by step, exactly what to do: "put this toy *there*, put
that toy up *there*".  (And, yes, the more SWYM-like entity can be
more resistant to doing things the *way* you want.  :)

At the same time, as compilers *multiplied*, more and more people
became dependent on exactly *how* they happened to do things -- i.e.,
though they were *evolving* to be more SWYM-like, these people
were relying on their *particular* copies to retain certain DWIS-like
characteristics.  Then, when they decide to upgrade, they've suddenly
got an *evolved* copy that doesn't behave they way they expect,
even though it might be behaving exactly as the developers want and
expect it to.

Here's where we are right now: gcc is kinda like the Arnold Schwarzenegger
robot in the movie Terminator.  You tell it something to do, and you
can pretty much guess how it'll do it, and be right most of the time,
so it's still fairly DWIS-like.  But it also has lots of SWYM-like
characteristics, of course -- for a sufficiently complicated task,
you *can't* predict exactly how it'll accomplish it.  You might think you
have *some* idea of how reliably you can predict some tasks, but you're
almost certainly wrong, even if you're its original programmer.  (The
Asimov series starting with "I, Robot" is, IIRC, an excellent introduction
to the sorts of problems that result from using automatons, including
assuming too much about how they will accomplish their tasks.)

So, if you've got a friend you want to intimidate and a Terminator
robot at your command, you can say "Terminator, go strangle my friend".

You *know* the robot will have to walk across the room to accomplish
this...that it'll make *lots* of noise and look *very* menacing doing
so...take a certain amount of time to do so...and that your friend
will get *real* scared.  At the last moment, you can say "Terminator,
cancel command" (or whatever), and you can all enjoy a good laugh.

But Terminator has some pretty serious limitations in terms of what
it can accomplish, and many of its users expect more of it.  In that
sense, it needs to become even more flexible -- more able to do tasks
in ways that would seem completely unpredictable.

Now, you hear about this *new* robot (in "Terminator II") and upgrade,
because you hear it'll do things faster, better, etc. than your
current robot, and you *gotta* have that, because while you love
the old robot, you've learned a lot about its limitations.

You try the same thing -- "Terminator, go strangle my friend" -- and
within about 50 milliseconds it has slithered small liquid-metallic
tendrils across the room, which crushed your friend's windpipe, all
without most of it apparently moving an inch.  Not so much laughter,
though you end up with more pizza and beer for yourself.

Now, is either robot completely SWYM?  No, nor completely DWIS.  Did
both robots do what you told them?  Yes.  Whose fault was it that
your friend got strangled?  Yours.

Why?  Because you failed to explicitly *constrain* the T2 robot to
meet your requirements -- requirements that were *implicitly* met
by the design limitations of the T1 robot, which the T2 robot neither
had, nor was designed to emulate.  You didn't say "*pretend* you're
going to strangle my friend, so he has time to see it coming and
get real scared, but don't actually do it", or something like that.

The designers of the C language, and of computer languages in general
(excluding Java, perhaps), just like the fictional designers of the
Terminator robots, know that The Future is in more SWYM-like designs.

They *also* know that, to keep complexity down, newer designs must
jettison archaic, DWIS-like constructs that existed primarily to work
around old limitations that they were superseding in the new designs
via more SWYM-like things.  (E.g. Fortran is likely to jettison COMMON,
EQUIVALENCE, and other "old favorites" someday, though it'll be some
time after before *compilers* actually do.)

So, as long as gcc is following the general path of implementing
standards like the C, C++, and Fortran languages, which are evolving,
almost exclusively, along SWYM lines, gcc will *have* to evolve, itself,
along SWYM lines.

And, to keep complexity down, it'll perhaps have to drop DWIS features,
and it certainly will have to stop accumulating new ones.  Heck,
we're *already* spending way too much time dealing with configury
issues (the Makefiles plus the configurations), largely because
make, originally intended to be SWYM-like, has accumulated features
and a culture that are too DWIS-like and thus too brittle, and because
of other DWIS-like stuff in that area (use of shell scripts, configure
scripts, etc.).  That doesn't even involve the code to do things
like read C programs, optimize them, and generate assembly, which
*should* be where we're spending the vast majority of our efforts!

As an OS developer, I've *long* appreciated the advantages of a more
DWIS-like compiler, and, in my experience, OSes are almost always
compiled by something *other* than the primary compiler being vended
for application code.  (At Prime, PRIMOS was written in assembler,
a FORTRAN-66 subset, and a small PL/1 subset called PL/P, and compiled
by the corresponding archaic compilers *long* after Prime offered
new, "better", FORTRAN 77, PL1/G, and full PL/1 compilers.  I recall
hearing that Sun used *gcc*, not its vended, unbundled compiler,
to compile either SunOS or Solaris for quite a while, though I
think they started switching away from that, last I heard around a
year ago.  Then there's BLISS at Digital, et al, but I don't have
much personal experience with these company's OS design efforts.)

So, I have *no problem* with someone meeting the need of OS developers
and embedded-software developers by providing a much more predictable
DWIS-like design.  It could even be an offshoot of gcc.

I just can't see any way gcc will be able to continue to evolve if it
takes on both roles, one SWYM-like, the other DWIS-like.  Heck,
look at the problems we're already having accommodating the two
*audiences*!  That is, there's *often* a clash here among the
SWYM-like audience that wants gcc to just "do the right thing"
to make their code faster, smaller, etc, the DWIS-like audience
that wants gcc to just do what they think they've told it to, and
the gcc developers, usually somewhere in between, who say "we're
trying to make it fast [a la SWYM] within the constraints of what
people actually expect beyond and above what the standard specifies
[a la DWIS]".

Also, I've long had high hopes that a much more comprehensive SWYM-like
language and compiler could actually *eliminate* the need for DWIS-like
tools in areas such as operating systems and embedded software,
by permitting SWYM expressions of external timing constraints,
for example.

That language won't be C, though, and probably not any other imperative
language currently fashionable (if it's even imperative at all).

Getting back to the proposal for a "force inline" directive, let me
ask a simple question, and see how you and others respond:

Would it *ever* be permissible for gcc to generate *different* code
from sources containing normal "inline", without warning at all
given `-Winline' (meaning it succeeds at all the requested inline),
as compared to the exact same sources compiled by the exact same
copy of the compiler, but with any of those normal "inline"s modified,
in the source, to be "force inline"?

In other words, does the simple act of specifying "force inline"
where "inline" used to *succeed* (as defined by `-Winline')
permit gcc to change the code it produces, perhaps radically?

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[craig]

>Christ Craig, give it a rest. This is a dead horse you're beating. Some
>reasonable sane and rational suggestions for solving the problems both with
>Linux and egcs have appeared; someone's found that a conditional compile
>can be used to make the extern inline thing compile and work on every gcc
>by either using __builtin_return_address or the label hack; Linus has said
>the panic code isn't too critical anyways and has apologized for some of
>the tirades earlier in the week; and it seems to be high time this issue
>was let drop on the list; yet I keep seeing more tirades from you every few
>minutes to an hour.

Yet, later, you followed up one of my "tirades" offering your own
opinions.  I guess it's okay if I don't respond to that?

Be aware that __builtin_return_address probably will stop working
someday in gcc.  Read my latest tirade to get an idea of why that is.

>BTW, did you know that your ISP's mail server was bouncing mail
>inexplicably all afternoon? Was bouncing messages with "Service
>unavailable". Never heard of downtime causing mail to bounce before;
>usually it's deferred. You should have a few stern words with your ISP's
>customer service reps about this; if the downtime had been much longer the
>bounces would have caused yo to be removed from this list and any others
>you're on more than likely. They should just defer the mail.

Do you have any bounced email to forward along, so I can see what
was actually happening?  That's the first thing my ISP would
ask for, probably.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Bill Kelly]

> Date: Sat, 13 Feb 1999 00:08:06 -0500
> From: Paul Derbyshire <pderbysh@usa.net>
> To: egcs@egcs.cygnus.com
> 
> Christ Craig, give it a rest.  This is a dead horse you're beating.

I think Craig's postings have been top-notch. It's rare when someone
both understands and is able to state so clearly the long-term design
issues he's tried to get across.

:-) His are the only articles I've saved from this thread, filed under:
~/news/c++/egcs.badass

> Some reasonable sane and rational suggestions for solving the problems both with
> Linux and egcs have appeared; someone's found that a conditional compile
> can be used to make the extern inline thing compile and work on every gcc
> by either using __builtin_return_address or the label hack; Linus has said
> the panic code isn't too critical anyways and has apologized for some of
> the tirades earlier in the week; and it seems to be high time this issue
> was let drop on the list; yet I keep seeing more tirades from you every few
> minutes to an hour.
> 
> BTW, did you know that your ISP's mail server was bouncing mail
> inexplicably all afternoon? Was bouncing messages with "Service
> unavailable". Never heard of downtime causing mail to bounce before;
> usually it's deferred. You should have a few stern words with your ISP's
> customer service reps about this; if the downtime had been much longer the
> bounces would have caused yo to be removed from this list and any others
> you're on more than likely. They should just defer the mail.

Yeah something is askew, neither of my local ISP's are able to even
_resolve_ jcb-sc.com.

Bill Kelly
<billk@cts.com>

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

>(BTW, I dislike macros too.  C is just too weak a language to get
>much done without them, though.  I had high hopes for C++ around
>10 years ago, but....)

But... what?
C++ is great. Templates, consts, ... no more macros exceptto
controlcompilation.
Now we just have to sit and wait for a compiler to come out that finally
supports the standard completely, from the standard library (including
<limits>) down to proper template linkage. Which some experimental egcs
snapshot is purportedly able to do.

[some deletia]

He didn't want lots of new features. He didn't even want a cross vendor
portable way to get a stack trace. He just wanted a way portable across GCC
implementations to get a stack trace.

>...new architectures, such as massively parallel machines,
>"massively serial" machines, etc.

"Massively serial"? By which you mean what, with thousands of cpu
registers, or terahertz clock rate, or...?


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

Christ Craig, give it a rest. This is a dead horse you're beating. Some
reasonable sane and rational suggestions for solving the problems both with
Linux and egcs have appeared; someone's found that a conditional compile
can be used to make the extern inline thing compile and work on every gcc
by either using __builtin_return_address or the label hack; Linus has said
the panic code isn't too critical anyways and has apologized for some of
the tirades earlier in the week; and it seems to be high time this issue
was let drop on the list; yet I keep seeing more tirades from you every few
minutes to an hour.

BTW, did you know that your ISP's mail server was bouncing mail
inexplicably all afternoon? Was bouncing messages with "Service
unavailable". Never heard of downtime causing mail to bounce before;
usually it's deferred. You should have a few stern words with your ISP's
customer service reps about this; if the downtime had been much longer the
bounces would have caused yo to be removed from this list and any others
you're on more than likely. They should just defer the mail.


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

Hey, wow, I actually agreed with everything Craig said. 

In article < 19990213001623.23023.qmail@deer >,  <craig@jcb-sc.com> wrote:
>
>The best thing gcc can do to help *everyone* is to be, generally,
>fairly predictable when it comes to making implementation decisions
>that aren't clearly wrong.
>
>And *that* is what Linus has been asking for all along, and what I've
>seen, I think, all the pertinent gcc developers agreeing to, even
>while they're saying "but don't *depend* too much on this".

Indeed. Right now, to me, it seems like there is _no_ sane way to do
what I want to do, and rely on what gcc will actually do. This is the
result of having a bad definition of what things do.

This is why I objected to the early suggestion to just make the
documentation even more uncertain on exactly what "inline" did.  I think
the problem in the first place was documentation that said "almost" and
"mostly" and "maybe" and "in a blue moon". 

When you have documentation like that, you can't but rely on
implementation, because the documentation doesn't actually give you
anything to depend on.  And then we end up in a situation where people
like me depend on implementation and implementors point fingers at bad
documentation. 

Testability goes to hell too. 

And yes, it's made worse by the fact that there _are_ actually sane ways
to do _exactly_ what I want to do, but they don't work with older
versions. People suggest I use #ifdef's etc, but that doesn't exactly
help testability either, and makes one of the points of using inline
functions go away completely - readability.

>It is *incredibly* challenging to design a language that allows
>programmers to specify just what they want to have happen *and*
>also allow them to specify exactly how the compiler is to make
>some unspecified thing happen.
>
>I call the former SWYM -- "Say What You Mean" -- defined as a
>specification from which not one single expression, operator,
>variable, whatever, can be removed without making the specification
>inviable.  I call the latter DWIS -- "Do What I Say" -- defined as
>a specification of how resources are to be employed, step by step,
>with as little information on what is actually the desired output
>as possible.

I guess I count as a DWIS person - I think that just is what C is
designed for.  In systems programming, you just can't let the compiler
do too many of the decisions for you. 

Obviously, C++ is very much a SWYM environment, and the compiler copes
best it can.  That's one of the reasons we very quickly discarded C++ as
a kernel language (we used to compile the Linux kernel with C++ a
_loong_ time ago, back when people still thought OO was a sexy
"must-have"). The compiler was just too unpredictable in many ways.

>In the meantime, it'd be a good idea to decide which direction
>gcc should go, which I think the industry as a whole has concluded is
>"SWYM", since that's where C's going, and stick with it, completely,
>or nearly, ignoring proposed extensions representing the other side,
>because C, as a language, cannot support both paradigms (it can
>barely support one).

I would hope you don't propose to go too far. In many areas, the main
strength of C is still as a reasonably portable low-level programming
tool that doesn't get in your face.

For SWYM, we already have things like visual basic,

		Linus

Re: kernel-2.2.1-undefined references.

[craig]

>The emails you quote are from the previous time this happened. As now,
>nobody actually suggested a good working way to do what we wanted to do
>without just completely resorting to macros (and I've already explained
>why I dislike macros). 

But, even if Linux developers didn't consider any of the proposals
as "a good working way", that didn't mean they were free to ignore
the *warnings*, which accompanied the proposals, about the dangers
of continuing to rely on the extensions in question as they were doing.

(BTW, I dislike macros too.  C is just too weak a language to get
much done without them, though.  I had high hopes for C++ around
10 years ago, but....)

>What you suggested then isn't any better than what you're suggesting now: 
>implementing new features in gcc doesn't obviate the need to be able to do
>the same thing with old code. And implementing a back-trace by hand is
>architecture- and compiler-dependent, which is silly because when that
>breaks due to compiler changes you'd just complain that we should do
>something else. You can't have it both ways, Craig. 

Of course, the code to do a limited back-trace would have to be part
of the system-specific, perhaps even compiler-specific, code that
pretty much any OS has.  I didn't imagine otherwise -- sorry if you
thought I was saying gcc somehow offered a feature to portably
obtain stack-trace information!

I do think there might be some feasability, depending on what it
is you're trying to accomplish *generally*, in the idea of
special pre-processing and/or post-processing of the source code
and assembler output.  It wouldn't be portable, but it might be
much more robust than anything we can feasibly do for you, and
more responsive to changes whenever your needs change, making your
project more tolerant of changes to gcc (for example).

But I don't know enough about what you need, on the whole, to really
offer any specific suggestions at this point.  I can only guess.

And that's part of why I, personally, would tend to resist adding
a new feature because you say it'll help you.  Not to be disrespectful
to you specifically, but generally, I find it is often the case
that a user asking for a new feature, in a situation where I don't
fully understand their need for it, won't find that new feature
completely addresses their problem, once I implement it.  So they'll
come back and ask for yet another new feature, to address the corner
cases or whatever they didn't previously think about.

In the end, if I'm not careful, I'll implement a handful of features
just for that kind of customer that are increasingly difficult for
users to really make good use of, hard for me to maintain, and which
don't really fully address the original problem.

>Face it: what Linux does is entirely reasonable, trying to get a backtrace
>in a architecture-independent way. Yes, it bit us, but it was certainly
>not an unreasonable thing to do.

I wouldn't call it "unreasonable".  But I think the implementation
of something like this should have been much more carefully studied
up-front, and/or, upon discovering it didn't always work if the
compiler had subtle changes made to it, an alternative quickly
looked-for, rather than blaming the compiler for changing.  (Though,
I still believe, we like to *know* when buglets like this creep in,
e.g. stuff stops inlining that really should inline in a reasonable
compiler.)

That relates back to my point about tolerances.  *We* want to know
when our compiler gets *near* the boundaries of its published
tolerances (and certainly when it exceeds those boundaries), but
we also want people to use it in ways that *accommodate* those published
tolerances, rather than assuming we'll always be able to keep it
within some unpublished, tighter tolerances.  Of course, they
can choose to ignore our advice, but they have to understand that
our priorities usually put bringing the compiler to *within* published
tolerances higher than *tightening* the compiler's tolerances
(which constitutes a promise of future performance and behavior).

This means you might get no help from the compiler doing what you
need.  That's unfortunate, but not necessarily the fault of the
compiler -- it might just mean the problem is better solved outside
the arena of the generation of optimized code from an "as if" language
like C.

>Do you really think it's unreasonable to ask for some way of forcing
>inlining, when the compiler obviously can do it? It doesn't have to be
>"extern inline", if you're afraid of polluting a future standard
>namespace. 

I think the complexity of just figuring out what exactly is *meant*
by "forcing inlining" probably greatly exceeds the benefits of
doing that, implementing the resulting specification, and maintaining
the it down the road.  For example, just how many copies of a
given invocation of inlined code end up in RAM; whether a
short-call interface may be used for inline code to quickly gain free
registers in a register-window machine like SPARC; whether
addresses of static variables are guaranteed to be unique across
all of the inlining "sites"; whether visible code-generation differences
between an inlined "maybe inline" and "always inline" would be permitted...
these would need to be nailed down, and not just by looking at the current
implementation, but by looking at what might be appropriate in the future,
for new architectures, such as massively parallel machines,
"massively serial" machines, etc.

Further, as I said in another post, which perhaps didn't go directly
to you, the C language upon which GNU C is based follows the "as if"
rule.  Much of the implementation of gcc assumes the "as if" rule.

Every extension and command-line option added to work around the "as if"
rule tends to not work very well and make gcc less maintainable
overall.

And, the "force inlining" phrase almost certainly connotes the idea
that "I don't mean *as if*, I mean *do exactly what I say*".  Though
there's no consensus likely to emerge anytime soon on exactly *what*
is meant by that, in implementation terms that make sense across
all current and future processors targeted by gcc.  (Please don't
say "it just means compile the code in line".  That means almost
*nothing*, just as "inline" itself means almost nothing!  For
your purposes, you'd need to offer exactly what visible semantics
you expect to take hold when forcing inline over not forcing inline,
or not inlining.)

In that sense, frankly, even if you *did* like using macros, you
wouldn't get a 100% guarantee of inlining, just like you wouldn't
when using any form of "inline".  That is, the compiler is free
to implement your repeated macro invocations as calls to a single
procedure, as long as they worked "as if" they were simply
code-generated as you'd currently expect.  Who knows, `-Os' might
someday be able to do that sort of thing, and people would certainly
want it to be able to.

I won't speak for the gcc developers who'll probably make the
decisions, but it's generally not wise to introduce extensions
outside the "zeitgeist" of a product just to satisfy a single
customer.  Even if you make that customer happy, it will be
only for the short term, in almost every case.  And I think the
"zeitgeist" for gcc is, despite a plethora of apparently "as-if-less"
extensions, strongly along "as if" lines.

So, is it "unreasonable" to ask for this?  No.  It's not unreasonable
for us to say "no", either, though.  If you haven't studied all
the code that gets involved in making inlining work, and making
subsequent processing phases properly account for inlining (in
terms of producing correct debugging info and so on), you might
take a moment to do so -- and then you might see while, on the whole,
it could indeed be unreasonable for us to decide to offer the
feature, even based just on how gcc *currently* does inlining and
ignoring how and when it might do so in the future.

But, that's for us to decide.  Even if *we* decide it's unreasonable
to provide the feature, that does *not* mean, IMO, that it's
unreasonable for you to ask for it.  Your job isn't to think
about the long-term viability of gcc, although I think we prefer
it when users give that some consideration *before* asking for
new features.

After all, it seems that much of this current debate stems from
one particular extension -- addresses of labels -- that seemed
entirely "reasonable" to add, long ago, and which has proved
handy, on occasion.  I think it's likely that the difficulties
that extension has caused exceeds the benefits it granted, compared
to if it hadn't been introduced in the first place.  (Maybe a
more Fortran-like feature, a quite simple but limited form,
would have been a better alternative, though even Fortran's
assigned GOTO has caused lots of pain over the decades.  And
it wouldn't have been useful for the skb_put type of case.)

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Benjamin Scherrey]

    Geez people lighten up! This is worse than the C++-in-kernel thread that
occurs in the linux list. I think we've identified what the issue is here
(right?). Now - who's the guy who makes the decision (Jeff?) and what's it going
to be?

    I think Linus and company are slightly aware of what the egcs team has
provided and I don't think your recitation was intended to clarify his mind. This
"discussion" is only wasting my time and every one else's who attempts to keep up
with this list.

    If the issue isn't completely understood by both sides yet perhaps Linus could
provide a couple of source examples (if he hasn't already - I haven't bothered to
read every tirade, err message in this thread) who's behavior has changed and an
egcs maintainer could either say "it will be fixed" or, at least, explain how one
might predict whether or not the code will inline as expected. The last I heard,
these computer things were still deterministic and truly random results were still
hard to generate...

    flame out,

        Ben Scherrey

craig@jcb-sc.com wrote:

> Which means, what, exactly?  That you therefore can claim some kind
> of *ownership* of the exact behavior of gcc in the presence of
> all sorts of extensions, regardless of the degree to which they're
> clearly specified and documented?  Sorry, you *should* know better.
>
> >There were tons of code generation bugs over time, but hey, I _expect_
> >bugs, and while compiler bugs are sometimes really hard and nasty to find,
> >I don't complain too much: I report them, and I tell people not to use
> >certain versions. I may be grumpy for a while because I spent ages looking
> >at a bug that didn't turn out to be mine, but I never get the feeling that
> >I should really dislike the compiler people.
>
> Given how you've treated the egcs developers lately, for daring to:
>
>   -  Offer you a free compiler
>
>   -  Offer you free upgrades
>
>   -  Offer you free responses to bug reports
>
>   -  Offer you free bug fixes
>
>   -  Offer you free improvements to unclear documentation
>
>   -  Offer you free advice as to how to improve your code to make
>      it more immune to likely changes to egcs code development
>
> I think we're *all* grateful you don't feel you should actually
> *dislike* us.

Re: kernel-2.2.1-undefined references.

[craig]

>Jeffrey A Law <law@hurl.cygnus.com> writes:
>
>> No.  ANy code which depends on a function being inlined for
>> correctness is broken.  That's it, there's no if and's or but's
>> about it.  The linux kernel depends on certain functions being
>> inlined and is therefore broken.
>
>In a strictly literal sense, I think you're right.  Perhaps this is
>better reported as a documentation bug rather than a compiler one.

It already was, long ago, and again more recently.  And the compiler
buglet(s) were fixed, though more might well occur, as well as non-bugs
that have the same effect as these buglets -- namely, stopping the
compiler from actually inlining some "extern inline" functions.

>I think it's unfair on Linus to criticize him, however.  He's made a
>reasonable interpretation of what the documentation says (it's how I
>read it, too) and this interpretation holds for more than one version
>of the compiler.

Please read my emails, from around six months ago, quoted in another
message, and the emails earlier in this thread, and ask yourself:

  "How many times have the Linux developers, and Linus in particular,
   been told that the documentation does *not* mean to promise that
   `extern inline' functions will be predictably inlined by any and
   all future versions of the compiler?"

What keeps happening, instead, is that, every time they are told
"you cannot count on `extern inline' always inlining", they ask
"then why not get rid of that construct?" or similar.  And they
never seem to learn from the answers they're given.

>His interpretation also strikes me as describing a useful feature: a
>macro dressed up as a function.  Of course there'll be examples of
>functions which wouldn't be inlineable, but surely when what I've got
>is basically a macro, it would be handy to be able to use function
>notation (in order to get argument copying, type checking, and so on)
>and to know that the thing will be treated as described in the
>documentation (but with the offending "most" replaced with "just about
>all"---with the exceptions being indirect calls and the like, I
>guess)?

Let me explain something.  I'll write this very slowly, so everyone
can keep up.  :)

The GNU C language is not a stand-alone, GNU-only language that happens
to be called "C".

The GNU C language is a set of extensions (some of which are some
combination of poorly thought-out, poorly specified, poorly designed,
poorly implemented, and poorly documented -- which is typical of
most vendor compilers for languages like C and Fortran, in my
experience) grafted onto an approximation (a pretty close one) of
a *standard* (or two or three) for the C language -- K&R C, ANSI C,
ISO C, and upcoming versions.

All of the *standards* upon which the GNU C language is based share
the following trait:

  The implementation (compiler, linker, libraries) may transform
  the program in any form, as long as the resulting behavior is
  "as if" the specified behavior occurred.

This (my approximate wording, but you get the idea) is known as the
"as if" rule.

For example, gcc, and any *other* C compiler, may transform the
relatively simple line of code, `a = b + c;', into a complex multiply,
as long as it acts "as if" it simply added `b' to `c' and stored the
result in `a'.  It could even execute the statement by writing `b' and
`c' to a file in /tmp, invoking `bc' to add the values and write
the result in `a', then read that back...etc.

It also means that, unless the specification for a vendors' compiler
*specifically* and *explicitly* suspends the "as if" rule for a
feature or extension, the compiler is free to choose any implementation,
as long as the resulting behavior is "as if" the direct description
was obeyed.

Since "inline" does not connote *any* specific semantic change in
the behavior of a program, it can *never* be assumed to make any
specific change in the *implementation* of that program (as produced
by the compiler, etc.).  That, simply put, is *not* the purpose of
"inline".

gcc offers, typically, extra-linguistic methods to sample, or perhaps
override, behaviors beyond the bright line of the "as if" rule.
For example, `-Winline' is claimed to do this: if inlining doesn't
actually happen, you get a warning.  (That's an example of what I
mean by "sample", since the warning can be safely ignored.)

But, the *linguistic* methods to sample or override these behaviors
are generally inappropriate in a language like C.  There are too many
combinations of too many things people would like to ensure, as far
as particular implementations, above and beyond what the specification
normally assures: precision of intermediate floating-point calculations;
precision of those intermediates if they get spilled; whether they can
get spilled; how overflows of integer computations are to be handled;
just to name a very few, involving some issues recently discussed here.

Each little audience will want its own particular "gimme", an
implementation-related bolt-on here, another kludge there.

If you want gcc to be almost completely unmaintainable within five
years, agree to provide just the proposed extensions that "make sense",
"seem useful", and "seem easy enough to implement" or for which "we
already have a patch".

An analogy I like to use is what the mathematician says in the movie
"Jurassic Park", something along the lines of "just because you
realized you *could* doesn't mean you *should*": just because we
*can* extend the language, implement the extension, and promote it
hither and yon via the power of open-source software and the Internet,
doesn't mean we *should*.

But, I know firsthand how easy it is to get caught up with our
new-found power to "move mountains" by tinkering with language
and interface designs, assuming we were given this power because
we were meant to actually wield it, day in and day out, as per
our whims, well-intentioned or otherwise.

>I confess I don't understand why there might be cases where functions
>*must* be inlined for correctness, but performance matters too:

C is not a language that provides an expression of desired performance.

Therefore, users of its compilers must themselves take responsibility
for the performance of their code.  Many of them do this by picking
a compiler vendor once, but the most demanding (or, demanded-upon) of
them figure out ways to verify that the desired performance levels are
achieved, for *each* compilation invocation, often by some combination
of tactics, including carefully studying the code output by the
compiler.

If a gcc user is depending on a particular performance level or
memory footprint from gcc, and isn't taking *independent* steps
to verify these are met, they're making a huge mistake, because
C is not a language designed to eliminate the need for humans to
engage in that sort of activity.

The best thing gcc can do to help *everyone* is to be, generally,
fairly predictable when it comes to making implementation decisions
that aren't clearly wrong.

And *that* is what Linus has been asking for all along, and what I've
seen, I think, all the pertinent gcc developers agreeing to, even
while they're saying "but don't *depend* too much on this".

The problem is, he and many others don't, or someday won't, agree
on what constitutes "clearly wrong".  Always inlining "extern inline"
in a way that disregards increased Icache usage is "clearly wrong",
though, when the compiler understands Icache usage -- which gcc
currently does not, but someday must, to remain competitive.  But
if it's "clearly wrong" to not inline an "extern inline" procedure
*today*, as people like Linus argue (mainly because they happen to
depend on another extension behaving in a manner not exactly specified,
meaning they're disregarding the "as if" rule), that means it'll either
still be "clearly wrong" then, or a promise, if it had been made, will
have been broken.

Either way, somebody suffers: the people who count on the compiler
to produce the most optimal code it knows how to produce at any
given time, or the people who count on the compiler to behave as much
as it used to behave as it possibly can.

So it is up to the gcc *developers* to specify, as clearly and simply,
what the language constructs and extensions do and do not guarantee,
along with guidelines regarding how they're currently implemented.

Doing that is a *lot* of work, and it has yet to be done.  For it
to be done, some people with *significant* expertise in the relevant
fields (technical writing, code generation, artificial-language
design, product development, user-interface design) would have to
expend a moderately significant effort.

Then, they'd have to *maintain* the documentation, all the while
helping the gcc (code) developers stick to the documented
interfaces and guidelined behaviors, and alert the writers to when
guidelined behaviors were going to change, so the docs could
be adjusted.

I don't see how that kind of effort will be seriously undertaken
as long as so many people insist on disputing what the documentation
says, disregarding the advice they're given as to how much to rely
on the documentation for assumptions about code generation, proposing
new extensions be added, and demanding old extensions be supported
exactly as they've always happened to work in the past.

In other words, to get where most gcc users probably want, ideally,
gcc to be, they should to encourage the gcc product to be "leaner
and meaner", so it can be more clearly specified, and documented,
over time.

Instead, what most everyone does is make suggestions that usually
*increase*, rather than *decrease*, the burden on the gcc development
team, when what is actually needed is to encourage the gcc product
to be "leaner and meaner", so it can be more clearly specified, and
documented, over time.

People who don't understand the above inevitably say "well, anyway,
I just want my feature, it isn't so hard to do, right?", and accuse
people like me, who actually understand the issues and how to meet
the challenge, of being in "ivory towers".  (I seriously doubt
the tower I'm in is "ivory", but it sure does give me a much wider
view of what's going on out there than I'd have if I just took the
day-to-day, let's-go-with-the-flow-and-implement-whatever-seems-popular,
approach.)

In the end, if the gcc user community can't tolerate keeping the
product lean and mean, they'll have to tolerate it being less well
documented and/or more buggy than otherwise.

>functions are more readable than longish macros with silly temporary
>variable names and things---people (for whom portability between
>compilers isn't critical) ought to be encouraged to use more readable
>mechanisms where possible, and providing suitable mechanisms is surely
>a Good Thing.

That's *certainly* true, and I heartily applaud that.

It is *incredibly* challenging to design a language that allows
programmers to specify just what they want to have happen *and*
also allow them to specify exactly how the compiler is to make
some unspecified thing happen.

I call the former SWYM -- "Say What You Mean" -- defined as a
specification from which not one single expression, operator,
variable, whatever, can be removed without making the specification
inviable.  I call the latter DWIS -- "Do What I Say" -- defined as
a specification of how resources are to be employed, step by step,
with as little information on what is actually the desired output
as possible.

(These definitions can pertain to layers of translation.  The
SWYM-like definition of a Fibonacci sequence is, in its ideal
form, not an imperative one -- it does not define the order
in which the numbers are generated, just the order in which
they occur correlated to the sequence of natural numbers.
A direct DWIS-like translation of that sequence can, in turn,
be viewed as a somewhat SWYM-like imperative program, which a
compiler is free to implement however it likes -- which is,
in turn, a DWIS-like translation that, to a CPU, is more
SWYM-like in that the actual ordering of operations isn't
necessarily obeyed as written, as long as the results occur
"as if" they were.)

So, the debate I see here, and often in other language/compiler
forums, boils down to this:

  Is this language destined to be more SWYM-like, or DWIS-like?

GNU C, and C in general, are on (perhaps stumbling along) a path
towards more SWYM-like behavior.

GNU C still tries to provide some DWIS-like features, but at
some point, it will be nearly impossible to maintain it without
making a choice between SWYM or DWIS.  And more and more DWIS-
like features get added to it all the time, unless people (like
myself) spend lots of time arguing against them, assuming we're
even successful.

That implies that every DWIS feature added makes it that much harder
to improve the SWYM characteristics of a language like C and/or
a compiler that supports it.

In fact, every *discussion* of a potential new feature, especially
a DWIS-like feature (which accounts for most of such discussions),
wastes time that could go to improving gcc in much more tangible
ways, assuming I'm correct in my estimate that the industry, as
a whole, wants more SWYM-like behavior from products like gcc.

>And, I imagine, in a kernel sometimes performance can
>affect correctness (though I may be quite wrong---I've lost the
>mention of which functions in the kernel were hit by this, and the
>"extern inline"s I can spot look like they shouldn't be critical).

Performance of a kernel, or a real-time process, is *crucial* to
correctness.  Same for other disciplines.

The short answer is, for those disciplines, C isn't *close* to
SWYM, and the programmers in those disciplines therefore tend to
program in a more DWIS-like fashion, and ask for more DWIS-like
features.

But, it is almost impossible for me to imagine enough DWIS-like
features being added to C (say, GNU C) to actually achieve what
they want: guaranteed meeting of performance criteria without
having to study the generated assembly code and/or do other kinds
of performance measurements.

Encouraging them to go down that path, by offering to add the
DWIS-like features they want (e.g. the "__force_inline" keyword
I proposed six months ago), leads them to a technological
cul-de-sac, and also leads to a compiler that just isn't likely
to make the huge numbers of SWYM-like-C users happy.

(An aside: what many Fortran vendors did, when Fortran 90 came
out, was simply offer Fortran 90 compilers that did not support
most of the extensions their still-current FORTRAN 77 compilers
supported.  That basically forced their users to choose between
the DWIS-like extensions they'd become accustomed to, in a product
line they could see would soon stop being developed, and the
SWYM-like features Fortran 90 offered as replacements for most
of the old extensions.  I'm not sure whether any Fortran 90
implementations exist that also handle all the old FORTRAN 77
extensions that are popular, but given what I know about the
effort needed to do that, I very much doubt a GNU Fortran 90
compiler will ever exist that does that.  Too Much Baggage.
Yet g77 users likely to fund a g90/g95 will tend to insist on a
"smooth upgrade path", meaning they won't want to have to drop
their use of extensions wholesale as they move up to a g90/g95.
So they'll have to fund a project several times as expensive
as otherwise necessary, which they're unlikely to do.)

And, in case you're wondering, yes, I've been thinking about
what a complete SWYM+DWIS development environment would look like,
from the ground up.  For over twenty years now.  Because I want to
be able to seamlessly move from programming in raw machine code all
the way up through full functional programming (*including* timing
requirements, still with no reliance on side-effect-based programming),
without having to jump in and out of the development environment and
its built-in programming language (with, perhaps, distinct dialects).

It's *incredibly* hard to do this right, and it, in my estimation,
puts a ton of new requirements on lots of areas that we currently
take for granted, like searching, editing, patching, documenting,
testing, and so on -- so *those* areas, seemingly, have to also
be included in the overall effort to redesign the system according
to SWYM+DWIS principles.

(Maybe this year I'll finally start to do something tangible towards
realizing this long-held dream, to see what I've got in my head,
and whether it makes any sense.)

In the meantime, it'd be a good idea to decide which direction
gcc should go, which I think the industry as a whole has concluded is
"SWYM", since that's where C's going, and stick with it, completely,
or nearly, ignoring proposed extensions representing the other side,
because C, as a language, cannot support both paradigms (it can
barely support one).

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 12 Feb 1999 craig@jcb-sc.com wrote:
> 
> P.S. Yes, folks, I realize that Linus almost certainly won't bother
> actually reading the below

I actually do real the email I get. I just don't have time to answer all
of it. I've answered most of the relevant postings (but not all of the
contents) in this thread because I feel strongly that there _is_ a real
need to have what I call a "working inline" while you obviously don't
think so.

The emails you quote are from the previous time this happened. As now,
nobody actually suggested a good working way to do what we wanted to do
without just completely resorting to macros (and I've already explained
why I dislike macros). 

What you suggested then isn't any better than what you're suggesting now: 
implementing new features in gcc doesn't obviate the need to be able to do
the same thing with old code. And implementing a back-trace by hand is
architecture- and compiler-dependent, which is silly because when that
breaks due to compiler changes you'd just complain that we should do
something else. You can't have it both ways, Craig. 

Face it: what Linux does is entirely reasonable, trying to get a backtrace
in a architecture-independent way. Yes, it bit us, but it was certainly
not an unreasonable thing to do.

Do you really think it's unreasonable to ask for some way of forcing
inlining, when the compiler obviously can do it? It doesn't have to be
"extern inline", if you're afraid of polluting a future standard
namespace. 

		Linus

Re: kernel-2.2.1-undefined references.

[craig]

>In article < 19990212031118.4271.qmail@deer >,  <craig@jcb-sc.com> wrote:
>>
>>The buglet in gcc has, I gather, already been fixed.
>
>Yes. 
>
>The sad part is that the bug was fixed several months ago. It was just
>re-introduced _again_ last week.
>
>>						  I haven't
>>gotten the impression the underlying bug(s) in Linux have, or
>>will, get fixed.
>
>Craig, have you actually bothered to look at the Linux use of "inline"
>at all? I don't think you have, and you're just spouting sh*t on the
>list. 

I realize you think that.  That's because you're rather uninformed,
or intentionally forgetful, about what has really been going on here,
and prefer to insult others than to take responsibility for mistakes
committed (repeatedly) on your end.

>It's not at all buggy, it just assumes that the compiler does something
>reasonable. 

No, it assumes that the compiler does something *some* people consider
reasonable, but others don't, and which is not *documented* by the
compiler to do any particular thing, implementation-wise.

>In particular, there are two kinds of "inline" in the kernel.  There's
>the "oh, I'd like to get this inlined" kind of inline, and there's the
>"consider this a macro" kind of inline. 

In other words, the kernel makes two uses of "inline", one that is
correct, the other that is incorrect.

>Please go and actually look at the sources you complain about.  I'm not
>an unreasonable person, I just get DAMN irritated when the same bug
>shows up twice in gcc, and people have a hard time even admitting it is
>a bug (I think the post by you is the first one that actually calls it a
>"buglet", finally - it's a bug, and yes, it was small, but by golly it
>was HARD to get people to even acknowledge it as one). 

First, I based my comments on what *you* were saying when *you* were
slinging mud at the egcs developers, the decisions they were making,
and the help they were offering you.

If you had wanted us to look at any sources, *you* should have posted
the relevant bits here first, perhaps in place of mud-slinging, which
you continue to prefer to engage in.

>Basically, Linux _does_ already use the "inline as hint" mentality: we
>have tons of functions that are marked "static inline" or just "inline". 
>Some of those functions are quite large, and some of them actually only
>make sense inlining on an alpha or other sane architecture that has tons
>of registers: and I'd be very happy if gcc actually decides at some
>point that "oh, this function just adds too much register pressure to
>make sense to inline on an x86". 

Fine and dandy.

>There's another class of "inline" usage, though - the "use as macro"
>class, because inline functions are often a _lot_ more readable than
>macros are, and you get tons of other advantages (the compiler does the
>argument copy so you don't have side effect problems, and often most
>importantly you get argument type-checking with good error messages with
>inline functions that you wouldn't get with a macro).  Those "use as a
>macro" inlines are marked, for the edification of gcc, as "extern
>inline". 

Which is incorrect, if the code actually *depends* on inlining
actually happening, as the documentation should have made clearer,
but most everyone already knew.

>Guess what? A lot of them _used_ to be "static inline", because "static
>inline" is safer (it works as expected in the presense of the address-of
>operator, and yes, if the compiler refuses to inline the thing because
>it's not optimizing, it will still create the function for you).  Most
>of them were _changed_ to "extern inline" mostly due to the gcc
>documentation.

Mostly due to an *incorrect reading* of the gcc documentation, which
didn't help things.

>So Craig, go and look at some of those "extern inline" functions. 
>Instead of just spouting crap on the mailing list without obvously never
>having even _looked_ at the problem.  All of them are _extremely_
>reasonable as far as I can tell - feel free to look for yourself.

More below on your continuing attack on my efforts to educate you
as to proper use of gcc extensions.

>The ones that were bitten by the egcs bug (let's just be honest and call
>it what it really was)

I have concluded that *you* wouldn't know "honesty" if it bit
you in the ass.  You have lied about this before, and you are
continuing to lie about it now.  egcs not inlining an "extern inline"
function is not, never has been, and never will be a bug.  The
*developers* might consider it a bug, in that they'd prefer some
cases be inlined for performance reasons, but to the user, it is
*never* a bug in the sense of violating the "contract" the compiler
makes with its users, in the form of an explicit language
specification.

In that sense, it's what I call a "buglet", meaning, not necessarily
a high-priority bug -- not a violation of the "contract", or
specification, of how the compiler behaves in terms of implementing
the language it compiles.

In writing the g77 documentation, I tried to make the distinction
between promises made on behalf of the GNU Fortran *language* and
the behavior of the current GNU Fortran *compiler* as clear as I could.

If, as a programmer, I don't see that clear a distinction in a product's
documentation, I assume *fuzziness*.

It's been *your* error that you've assumed that any behavior you observe
and which the gcc documentation doesn't clearly say might change will
therefore be promised for all of eternity.  That's a *very* frequent
error, but rare is the person who insists on insulting those who
try and point it out to him, especially as repeatedly and as nastily
as you've done.

>were so small that it would have been completely
>unreasonable for any good compiler to not inline them.  They were
>essentially two assignments and a copy, they just happened to have the
>address-of-label thing in some debugging code (because all other gcc
>methods of getting the current PC have been buggy at various points). 

The only reasons it should have mattered to you that inlining did
not happen are that you didn't get the performance you want, or
the generated code was actually wrong.  Neither was the case.  Therefore,
if the overall result was that *your* code broke, it was not *egcs*
that broke it -- it was a change to egcs that triggered a long-hidden
bug in your code.  Please stop saying things like "this change broke
egcs", as that's a lie.

>Basically, Craig, just come down from your ivory tower and look at the
>code, and I'd be surprised if you didn't agree with me that Linux
>"extern inline" usage actually makes sense if you were to just spend a
>_small_ amount of time actually looking at it instead of spouting off
>without knowing what's up.

Okay, Linus, now that you've *totally* destroyed any and all credibility
you've *ever* had with me, and converted me from promoting your
abilities, and Linux, to friends and neighbors to warning them away
from anything you touch, I'll enclose a copy of some emails sent *six
months* ago on a closely-related issue.

I want you to read these emails *very* carefully, and then come back and
explain exactly how you still believe I'm simply up in an "ivory tower",
have never had a "look" at code *you* have not (to my knowledge)
offered here, and how I should still agree that Linux' use of
"extern inline" as "guarantee me inlining" makes sense.

(For *other* readers, who *are* allowed to not bother reading the
emails quoted below: the summary is, this problem came up before,
was specified as being related to Linux, and was *thoroughly* and
*completely* explained as being the result of a combination of
poorly-specified extensions, inadequate documentation, and Linux'
inappropriate reliance on the behavior of extensions.  Further,
viable alternatives were proposed.  Apparently that did no good
then, though I'm willing to take the blame for not fixing the
gcc docs myself, and there is plenty of reason to assume all this
verbage will do no good now.)

        tq vm, (burley)

P.S. Yes, folks, I realize that Linus almost certainly won't bother
actually reading the below, as he's already cast my posts on this
topic as "silly" and so on.  I'm writing all this for the public
record, basically: I want it clearly on record that Linux developers
(which I assume included David Miller, involved in the emails below)
were *warned* about this problem, told to change their code and
how to properly read the documentation *months* ago, that Linus
himself continually and repeatedly ignores the same advice given
now and insists on continuing to tell the lie that egcs is the
source of the problem.  It does *not* matter to me whether Linus
ever "gets" it, all things considered.


>Date: Tue, 28 Jul 1998 11:36:27 -0400 (EDT)
>From: Craig Burley <burley@gnu.org>
>To: davem@dm.cobaltmicro.com
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
>        rth@cygnus.com
>Cc: burley@gnu.org
>In-reply-to: <199807281242.FAA31050@dm.cobaltmicro.com>
>	(davem@dm.cobaltmicro.com)
>Subject: Re: inline functions and local labels
>
>>   Date: Tue, 28 Jul 98 08:36:39 EDT
>>   From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
>>
>>   Inlining tells the compiler "for efficiency reasons, I'd like you to
>>   do your best to inline this function", not "even if you do it wrong, I'd 
>>   like you to inline it".
>>
>>Then what does "extern inline" say?
>
>It says "if you can inline this function, great, but even if you can't,
>don't compile it as a separate function".  E.g. if you compile without
>optimization, it doesn't get inlined.
>
>>Forget for a moment what you know about C and compiler implementation
>>details, and all of the issues surrounding this topic.  And pretend
>>for a moment you are a programmer using GNU C to accomplish some task
>>and you wish to express something, and you find that GNU C allows you
>>to express this by saying:
>>
>>extern __inline__ check_a(int a)
>>{
>>	__label__ here;
>>
>>	if(my_test(a) != 0)
>>		printf("Assertion on 'a' failed at %p\n", &here);
>
>(I think that should be `, &&here'.)
>
>>&&here:
>
>(I think that should be "here:".)
>
>>}
>>
>>Can you tell me that this does not seem like a useful construct or
>>feature?  Can you also tell me that this is hard for the person
>>writing such code to understand?  Which behavior of the above function
>>do you deem would be correct in any case?
>
>I'm confused -- what are the choices?  I've already tried to construct
>an example showing the differences, and can't do so without resorting
>to bogosities like having some external code somehow depend upon
>the uniqueness, or value, of labels passed to it as `void *' arguments.
>(See below for an example.)
>
>>It depends, for standard C constructs, I can understand this
>>completely.  For GNU C extensions, we can say whatever we like about
>>semantics wrt. inline functions, and in fact document them.
>
>I think we should first figure out whether the proposed semantics
>make good linguistic sense in the first place.  When I first looked
>into this as a result of this discussion, I *thought* there were some
>very interesting issues here, but so far all I can find is places
>in the gcc docs where we could do a better job clarifying stuff
>most programmers would regard as "natural" for them (and perhaps
>in disagreement with each other).
>
>>This issue is different from most others, because it is an issue of
>>semantics when two different GNU C extensions are used together, so we
>>can define the semantics any way we wish to in such cases.  I contend
>>that the current behavior makes the most sense and is the most useful
>>for users of GNU C (the fact that this behavior has been in known
>>active use for 4 or 5 years is a testament to this!).
>
>I'm still confused as to what the current behavior *is* that is
>being depended upon.
>
>My *guess* is that the current behavior is to try and inline functions,
>which is not always done.  That's what the docs say (especially if you
>read carefully, and between the lines -- they could stand improving
>though).
>
>What exactly *breaks* when code like the examples you post aren't
>actually inlined by gcc?  If it's just that you get unresolved
>references to the externals, well, that's what is *supposed* to happen,
>based on my reading of what `extern inline' means in gcc.
>
>If it's just that when the code doesn't get inlined, the application
>(Linux?) goes slower, well, that's not a linguistic or semantic
>issue -- even if the decision revolves around whether a construct
>like `&&foo' is present.
>
>If that's the case, then it's just a matter of the application no
>longer using `&&foo', or teaching gcc to change that decision again
>(but only when it's safe to do so, to preserve the semantics of
>the function), or teaching gcc a new construct meaning "*inline* this,
>dammit!", such as __force_inline__.  Programmers would be responsible
>for any code-generation bugs resulting from their combining this
>specification with features gcc normally would detect as "I can't
>safely inline this".
>
>
>As far as how hard it is to tell what labels should really "mean",
>here's a contrived example:
>
>#include <stdio.h>
>
>void *
>f (void *arg)
>{
>  static void *x = NULL;
>  void *y;
>
>  if (x == NULL)
>    {
>      x = arg;
>      return arg;
>    }
>
>  y = x;
>  x = arg;
>  return y;
>}
>
>inline int
>myjump ()
>{
>  __label__ bar;
>  void *f();
>  void *foo;
>  static int myval = 1;
>
>  foo = f(&&bar);
>  goto *foo;
>
>bar:
>  return myval++;
>}
>
>int
>main()
>{
>  int i;
>  int j;
>  int k;
>
>  i = myjump();
>  j = myjump();
>  k = myjump();
>  printf ("%d %d %d\n", i, j, k);
>  return 0;
>}
>
>Compiled using gcc 2.8.1 or egcs, without optimization, it prints
>"1 2 3", but with enough optimization to cause inlining, it prints
>"2 4 5" on my RH 4.2 Linux system, probably because the label
>feature is being abused (which gcc doesn't detect, but it does
>print "interesting" warnings about `i' and `j' when inlining, so
>perhaps it could detect this?).
>
>So, depending on the nature of code labels, vis-a-vis whether they're
>static a la variables, or static on a per-copy-of-function basis, seems
>to be unwise.  Even though the gcc docs don't seem to explicitly disallow
>such use, they don't allow it either, and wise programmers wouldn't
>depend on such behavior.  (Not only does the code above not work,
>but neither would depending on the equality of a `void *'-passed label
>determining whether the calling function was the same as some previous
>caller, or some such thing, be wise.)
>
>I suggest we revise the gcc docs regarding labels to clarify that
>any addresses of labels taken within a function during its invocation
>become invalid as soon as the function returns, just as is the case
>for passing `&a' given `int a;' within a function.
>
>We probably also should specify that comparing labels as addresses is
>not a reliable way to determine whether they refer to the same, or
>different, addresses.  That is, &&foo and &&bar, even within a single
>function invocation with foo and bar being labels on different chunks
>of code, could evaluate to equal (gcc could place the generated code
>in the same place in memory, and use state info to disambiguate the
>code at run time), and perhaps even &&foo and another &&foo could
>yield different addresses within the same function (gcc could "flatten"
>programmer-visible state info into distinct code sequences, as long
>as it preserves the correctness of "goto *label;" following each
>corresponding "label = &&foo;").
>
>I think it's okay to allow passing &&label to another procedure, though,
>as long as the lifetime of that argument is the calling function
>invocation's lifetime, and the only use of the argument is to return
>the value back to the function or to print it out (or otherwise make
>it available) for debugging/logging purposes.
>
>Also, perhaps we should clarify the text on "inline" so readers know
>it is never safe to depend on inlining of any given function always
>happening.  It's already said, but perhaps not clearly enough --
>some of the verbage seems to suggest otherwise in a few places, and
>not everyone reads the entire description before jumping to
>conclusions.
>
>In summary, I haven't seen any clear description of the semantic
>lossage being complained about, and can only guess that the problem
>is that gcc has decided to stop inlining something it used to inline,
>which is not great, but not a semantic problem, just an optimization
>issue that bare-to-the-metal coders must deal with on an ongoing
>basis.  (To wit: if these functions hadn't *previously* been inlined
>due to their using &&foo, would the programmers have nevertheless
>used that feature, and given up the inlining, or given up &&foo?
>Either way, that's what they *can* do now, although ideally they
>shouldn't be made to choose.  And they can macro-ize their way out
>of relying on &&foo, if they like.)
>
>I do wonder if a "pointer to `here'" feature might be useful in
>place of what I gather is a kludge to get some kind of pointer
>useful for debugging, logging, and so on.  Perhaps `&& .' or
>`&& __label_here__' or similar could be reserved for that purpose,
>and be valid *only* as a `void *' that can be copied, printed, written
>to a file, etc., but not as the target of a `goto *x;' or any
>other pointer-like operation (++, +, -, ==, unary *, etc.).
>
>        tq vm, (burley)


>Date: Tue, 28 Jul 1998 20:00:13 -0700
>From: "David S. Miller" <davem@dm.cobaltmicro.com>
>To: burley@gnu.org
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
>        rth@cygnus.com, burley@gnu.org
>In-reply-to: <199807281536.LAA11100@melange.gnu.org> (message from Craig
>	Burley on Tue, 28 Jul 1998 11:36:27 -0400 (EDT))
>Subject: Re: inline functions and local labels
>References:  <199807281536.LAA11100@melange.gnu.org>
>
>   Date: Tue, 28 Jul 1998 11:36:27 -0400 (EDT)
>   From: Craig Burley <burley@gnu.org>
>
>   I'm confused -- what are the choices?  I've already tried to
>   construct an example showing the differences, and can't do so
>   without resorting to bogosities like having some external code
>   somehow depend upon the uniqueness, or value, of labels passed to
>   it as `void *' arguments.  (See below for an example.)
>
>Craig, I apologize, I should have posted the code which behaves
>differently if not inlined (due to kenners patch) so that the behavior
>issue in question is more clear.  There is a performance concern, but
>this is secondary compared to the loss in functionality change:
>
>extern __inline__ unsigned char *skb_put(struct sk_buff *skb, unsigned int len)
>{
>	unsigned char *tmp=skb->tail;
>	skb->tail+=len;
>	skb->len+=len;
>	if(skb->tail>skb->end)
>	{
>		__label__ here; 
>		skb_over_panic(skb, len, &&here); 
>here:		;
>	}
>	return tmp;
>}
>
>We use this for debugging, and the debugging information becomes
>useless if the procedure is not inlined.
>
>Later,
>David S. Miller
>davem@dm.cobaltmicro.com


>Date: Wed, 29 Jul 1998 12:33:49 -0400 (EDT)
>From: Craig Burley <burley@gnu.org>
>To: davem@dm.cobaltmicro.com
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
>        rth@cygnus.com
>Cc: burley@gnu.org
>In-reply-to: <199807290300.UAA05668@dm.cobaltmicro.com>
>	(davem@dm.cobaltmicro.com)
>Subject: Re: inline functions and local labels
>
>>Craig, I apologize, I should have posted the code which behaves
>>differently if not inlined (due to kenners patch) so that the behavior
>>issue in question is more clear.  There is a performance concern, but
>>this is secondary compared to the loss in functionality change:
>[...]
>>We use this for debugging, and the debugging information becomes
>>useless if the procedure is not inlined.
>
>Ah, I think I get it now.
>
>What you *want* is to "dump" the address of the caller's reference
>to the current function, so the ability to quickly localize the
>cause of the problem is improved somewhat.
>
>What you're *using* to get this is something different, which sometimes
>amounts to the same thing (e.g. when the code is inlined), but
>sometimes doesn't (e.g. when it isn't).
>
>A new notation added to gcc might be handy here (a notation that
>would basically be of roughly the same class as __PRETTY_FUNCTION__,
>though it'd involve lower-level code-gen issues than that).
>
>But it seems to me it'd be more worthwhile to consider implementing
>a general way to print a limited stack backtrace, which is an issue
>outside the language definition, and would require less cruft in
>your code overall.
>
>        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[craig]

>On 12 Feb 1999 craig@jcb-sc.com wrote:
>> 
>> >To _me_, "standard C" has not been important at all. I'm _more_ than happy
>> >to use gcc extensions, because I think they are worthwhile in the kernel. 
>> 
>> That means, like I already said, you have to be prepared for a very
>> bumpy ride.  You've shown that you have trouble coping with that.
>
>Umm..
>
>I had no problems with gcc features for about six or seven years of Linux
>development. These things simply didn't use to happen: despite upgrading
>_major_ versions of gcc (when Linux started we were using gcc-1.40), for
>those six-seven years there weren't really any changes that I ever had
>problems with. 

Which means, what, exactly?  That you therefore can claim some kind
of *ownership* of the exact behavior of gcc in the presence of
all sorts of extensions, regardless of the degree to which they're
clearly specified and documented?  Sorry, you *should* know better.

>There were tons of code generation bugs over time, but hey, I _expect_
>bugs, and while compiler bugs are sometimes really hard and nasty to find,
>I don't complain too much: I report them, and I tell people not to use
>certain versions. I may be grumpy for a while because I spent ages looking
>at a bug that didn't turn out to be mine, but I never get the feeling that
>I should really dislike the compiler people. 

Given how you've treated the egcs developers lately, for daring to:

  -  Offer you a free compiler

  -  Offer you free upgrades

  -  Offer you free responses to bug reports

  -  Offer you free bug fixes

  -  Offer you free improvements to unclear documentation

  -  Offer you free advice as to how to improve your code to make
     it more immune to likely changes to egcs code development

I think we're *all* grateful you don't feel you should actually
*dislike* us.

>The reason I have been complaining so much lately is that I think that the
>egcs development has lost that stability. Again, never mind code
>generation bugs, I'm talking about _interface_ stability. I've had much
>more problems in the last year than I had in the seven years preceding
>this.

Yet, that's *exactly* the kind of symptom I would *expect*, speaking
objectively, given the problems *I've* been claiming exist here.

In short, you're saying that you decided long ago to depend mightily
on particular implementation details of gcc, despite not having a
clear specification constituting a promise that those details would
not change in future versions of gcc.

For several years, as gcc development slowed down more and more, including
around two years when *no* major changes were made in released versions,
you experienced no problems.

Then, when the floodgates of development were opened, and development
increased to a heretofore-unknown level of activity, suddenly you
ran into nasty surprises as the (sometimes-obscure, like regparm)
extensions you relied upon stopped working as they used to.

Linus, there is *nothing* surprising in that, and *nothing* that
suggests the problem is due to the attitude of the egcs developers,
or the pace of egcs development.  Even if egcs had been "perfectly"
developed in this regard, the results would have been better
documentation of the limitations of "extern inline" and addresses
of labels, which you probably wouldn't have noticed changed, and/or
vehemently disagreed with the "direction" in which egcs is going.
(By proof, I offer the fact that, now that we're fixing this, you're
*still* arguing.)

There are *plenty* of people who are quite happily continuing to use
egcs on their codes, as it evolves, because *they* wrote *their* codes
to properly use the pertinent languages.  (To the extent they're
not happy with bugs, I suppose they're wondering why we're wasting
our time accommodating your use of obscure extensions when we could
be making specification-conforming code actually work in the first
place, go faster, be smaller, etc.)

>This may actually not be due to technical reasons as much as simply due to
>a different open development model - it may just be that more people see
>"partial" work, and some of that partial work breaks stuff. Fine - I like
>open development myself, and I use it. But when somebody complains to _me_
>that I broke old interfaces, I consider that a bug unless I have a very
>very strong technical reason to tell people that I simply _cannot_ support
>some old interface any more. 

You cannot support the "extern inline" interface anymore, as a promise
that inlining will happen.  There, I said it, others have said it,
and the strong technical reasons are that *gcc* will not promise it
to you, nor will any *other* compiler that undergoes any useful
development over the next 10-20 years.

>In contrast, on this list, when people complain that egcs breaks existing
>code, the answer is "shut up and live with it" - and then they Cc: me on
>the damn thing. And that's why I get so upset, and why these flame-wars
>erupt. 

I didn't see those answers.  FIrst thing *I* noticed was *your* flames.

If you want to send along a few pointers to the earlier posts, I
wouldn't mind reading them to see what you're talking about.

>"Shut up and live with it" is not a way of caring for your customers. And
>creating the best compiler in the world is not just about code generation:
>it's about supporting the people that use it, too. 

I agree with that.  I'm not claiming egcs is perfect in this regard.

What I *do* know is that you've caused many of us to burn lots of time
on what was a non-issue, long-ago dealt with, but ignored by,
apparently, at least one Linux developer in the past.

And if you think it is *our* job to support *you*, ask yourself how
many donations you've made to egcs developers lately, and compare
that to your recent tendencies (not just in this thread) to accuse
them of breaking your code and then not listening to their explanations
regarding how you can avoid these problems in the future.

>I could change my kernel interfaces and tell people that "shut up,
>recompile, and be happy". Trust me, that doesn't work when you have a
>serious project that you expect others to be serious about too. I make
>_damned_ sure that I don't break binaries, and when I do it by mistake I
>have egg on my face and I fess up to screwing up. 

Look, I probably care more, and perhaps know more, about preserving
the integrity of interfaces to products like kernels and compilers
than most anyone on the egcs or Linux development teams.  I say that
not so much because of my technical abilities vis-a-vis programming
(which aren't bad), but because of my understanding that you don't
*get* integrity of interfaces without *first* starting with a
solid design, specification, development, and *documentation* effort.
And I've got a pretty good understanding of what *those* entail,
and how rarely they're practiced in much of the software industry.

That's why I've taken the time to so *carefully* explain to you,
and others, exactly why your assumptions about "extern inline" are
wrong, and even if you manage to wrangle a promise about to preserve
them from some well-meaning egcs developers *today*, that promise
will someday be broken.

Yet, because I've *dared* cross the Great Linus Torvalds, you've
taken to trashing *my* posts as "silly", claim I'm posting "sh*t",
"crap", and so on.

There's not a *single thing* I've said in these posts that has been
shown to have been even remotely incorrect, aside from my realizing
I might have confused you and David Miller in the emails about
this issue six months ago.  Much of what I said is valuable guidance
for people working on projects that have nothing to do with either
egcs or Linux, and represents the understanding I've gained by working
on OS, tool, interface, and compiler development and documentation
for nearly 30 years now.

But, to you, it means *nothing*, because you apparently don't value
actually using *documented interfaces* correctly in the first place,
meaning that if an interface isn't clearly specified, don't make
assumptions about it.

>On this list, nobody 'fesses up to screwing up any more. And that's sad. 
>It makes the egcs project look less serious, and more like a bunch of
>people that just want to play at making a commercial-grade compiler. 

We admitted the documentation needed improving.  I *think* that has
happened already (if not, I'll do it myself).  And we apparently
fixed the buglet that triggered the bugs in your code, so you can
ignore those for awhile longer if you want.

If that isn't admitting to screwing up, I don't know what is.  I know
it isn't exactly *what* you think we should have admitted to.  But
if we admitted that the whole problem was the the compiler needed
to *always* ensure inlining of "extern inline", you'd *love* that
response, pat us on the heads, and say "good jobs", but we'd have
implicitly made a promise we could not possibly keep down the road.

But it's *our* compiler.  It's *our* documentation.  It's *our*
language specification.  Therefore, *we* get to decide which of
these are broken, when conflicts like this arise.

I'm pretty confident the right decision has been made.  I'm absolutely
*certain* you haven't presented sufficient reasons, to date, to have
made a different decision.

And it's also quite clear you have *zero* respect for the decisions
made by us about our product.  So if you like them, you're happy, and
if you don't, you flame us, and anybody like myself who comes along
and tries to explain them to you in more detail.

So all your PR efforts at trying to rah-rah us into being better
compiler developers don't amount to much, since we can all see
what you *really* care about: getting us to do exactly what you say,
without question, without thought, even if that includes making
promises we *know* we can't keep.

If you *really* value what we're doing here on the egcs project,
you'll not say *one more word* on this topic, except perhaps for
offering some pretty serious apologies, if you've got the integrity
to do that.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Jeffrey A Law]

  In message < 7a2691$cf9$1@palladium.transmeta.com >you write:
  > In article < 9211.918849009@hurl.cygnus.com >,
  > Jeffrey A Law  <law@hurl.cygnus.com> wrote:
  > >
  > >  In message < 7a203j$9cf$1@palladium.transmeta.com >you write:
  > >  > 
  > >  > The sad part is that the bug was fixed several months ago. It was just
  > >  > re-introduced _again_ last week.
  > >
  > >No.  This is not what happened.  Please don't state this as a fact since y
  > ou
  > >do not know the facts.  If you would like to know the facts, then ask.
  > 
  > I was _there_, Jeff. The bug got introduced in the gcc-2.8.x development
  > tree,
Yes.

  > and we had this same discussion - it just happened to be more
  > private.
We were discussing how to deal with the problem in egcs when we sucked in that
code.  Not what to do with gcc2.

  > The bug was fixed back then by Richard Henderson, he just
  > didn't get permission to check in his fix.
He had permission to check in the fix to the egcs tree when we sucked in the
offending gcc2 code.  You can't blame rth or the egcs project for the inability
to get a change into the gcc2 tree as we have zero control over what goes into
that tree.

  > The bug then re-appeared in egcs apparently simply due to a merge with
  > gcc-2.8.x, exactly because rth hadn't gotten his fix in originally.
Not exactly.  Again, rth had permission to fix this problem when it came into
our tree due to the merge.  And that is precisely what happened.

Get your facts straight please.

jeff

Re: kernel-2.2.1-undefined references.

[Bruce Stephens]

Jeffrey A Law <law@hurl.cygnus.com> writes:

> To: torvalds@transmeta.com (Linus Torvalds)

[...]

>   > It's not at all buggy, it just assumes that the compiler does something
>   > reasonable. 

> No.  ANy code which depends on a function being inlined for
> correctness is broken.  That's it, there's no if and's or but's
> about it.  The linux kernel depends on certain functions being
> inlined and is therefore broken.

In a strictly literal sense, I think you're right.  Perhaps this is
better reported as a documentation bug rather than a compiler one.

I think it's unfair on Linus to criticize him, however.  He's made a
reasonable interpretation of what the documentation says (it's how I
read it, too) and this interpretation holds for more than one version
of the compiler.

His interpretation also strikes me as describing a useful feature: a
macro dressed up as a function.  Of course there'll be examples of
functions which wouldn't be inlineable, but surely when what I've got
is basically a macro, it would be handy to be able to use function
notation (in order to get argument copying, type checking, and so on)
and to know that the thing will be treated as described in the
documentation (but with the offending "most" replaced with "just about
all"---with the exceptions being indirect calls and the like, I
guess)?

I confess I don't understand why there might be cases where functions
*must* be inlined for correctness, but performance matters too:
functions are more readable than longish macros with silly temporary
variable names and things---people (for whom portability between
compilers isn't critical) ought to be encouraged to use more readable
mechanisms where possible, and providing suitable mechanisms is surely
a Good Thing.  And, I imagine, in a kernel sometimes performance can
affect correctness (though I may be quite wrong---I've lost the
mention of which functions in the kernel were hit by this, and the
"extern inline"s I can spot look like they shouldn't be critical).

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

In article < 9211.918849009@hurl.cygnus.com >,
Jeffrey A Law  <law@hurl.cygnus.com> wrote:
>
>  In message < 7a203j$9cf$1@palladium.transmeta.com >you write:
>  > 
>  > The sad part is that the bug was fixed several months ago. It was just
>  > re-introduced _again_ last week.
>
>No.  This is not what happened.  Please don't state this as a fact since you
>do not know the facts.  If you would like to know the facts, then ask.

I was _there_, Jeff. The bug got introduced in the gcc-2.8.x development
tree, and we had this same discussion - it just happened to be more
private. The bug was fixed back then by Richard Henderson, he just
didn't get permission to check in his fix.

The bug then re-appeared in egcs apparently simply due to a merge with
gcc-2.8.x, exactly because rth hadn't gotten his fix in originally.

>  > It's not at all buggy, it just assumes that the compiler does something
>  > reasonable. 
>
>No.  ANy code which depends on a function being inlined for correctness
>is broken.  That's it, there's no if and's or but's about it.  The linux
>kernel depends on certain functions being inlined and is therefore broken.

Why don't you remove "extern inline" completely, then? It serves no
useful purpose, it seems.

		Linus

Re: kernel-2.2.1-undefined references.

[Jeffrey A Law]

Opps, cc to egcs was botched.

---

To: torvalds@transmeta.com (Linus Torvalds)
cc: submit-linux-egcs@transmeta.com
Subject: Re: kernel-2.2.1-undefined references. 
Reply-To: law@cygnus.com
In-reply-to: Your message of 12 Feb 1999 19:40:35 MST.
             < 7a203j$9cf$1@palladium.transmeta.com > 
Date: Fri, 12 Feb 1999 12:48:32 -0700
Message-ID: <9186.918848912@hurl.cygnus.com>
From: Jeffrey A Law <law@hurl.cygnus.com>


  In message < 7a203j$9cf$1@palladium.transmeta.com >you write:
  > In article < 19990212031118.4271.qmail@deer >,  <craig@jcb-sc.com> wrote:
  > >
  > >The buglet in gcc has, I gather, already been fixed.
  > 
  > Yes. 
  > 
  > The sad part is that the bug was fixed several months ago. It was just
  > re-introduced _again_ last week.
No.  This is not what happened.  Please don't state this as a fact since you
do not know the facts.  If you would like to know the facts, then ask.

  > It's not at all buggy, it just assumes that the compiler does something
  > reasonable. 
No.  ANy code which depends on a function being inlined for correctness
is broken.  That's it, there's no if and's or but's about it.  The linux
kernel depends on certain functions being inlined and is therefore broken.

jeff

- --LAA12836.918848952/neon.transmeta.com--


------- End of Forwarded Message

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

In article < 19990212031118.4271.qmail@deer >,  <craig@jcb-sc.com> wrote:
>
>The buglet in gcc has, I gather, already been fixed.

Yes. 

The sad part is that the bug was fixed several months ago. It was just
re-introduced _again_ last week.

>						  I haven't
>gotten the impression the underlying bug(s) in Linux have, or
>will, get fixed.

Craig, have you actually bothered to look at the Linux use of "inline"
at all? I don't think you have, and you're just spouting sh*t on the
list. 

It's not at all buggy, it just assumes that the compiler does something
reasonable. 

In particular, there are two kinds of "inline" in the kernel.  There's
the "oh, I'd like to get this inlined" kind of inline, and there's the
"consider this a macro" kind of inline. 

Please go and actually look at the sources you complain about.  I'm not
an unreasonable person, I just get DAMN irritated when the same bug
shows up twice in gcc, and people have a hard time even admitting it is
a bug (I think the post by you is the first one that actually calls it a
"buglet", finally - it's a bug, and yes, it was small, but by golly it
was HARD to get people to even acknowledge it as one). 

Basically, Linux _does_ already use the "inline as hint" mentality: we
have tons of functions that are marked "static inline" or just "inline". 
Some of those functions are quite large, and some of them actually only
make sense inlining on an alpha or other sane architecture that has tons
of registers: and I'd be very happy if gcc actually decides at some
point that "oh, this function just adds too much register pressure to
make sense to inline on an x86". 

There's another class of "inline" usage, though - the "use as macro"
class, because inline functions are often a _lot_ more readable than
macros are, and you get tons of other advantages (the compiler does the
argument copy so you don't have side effect problems, and often most
importantly you get argument type-checking with good error messages with
inline functions that you wouldn't get with a macro).  Those "use as a
macro" inlines are marked, for the edification of gcc, as "extern
inline". 

Guess what? A lot of them _used_ to be "static inline", because "static
inline" is safer (it works as expected in the presense of the address-of
operator, and yes, if the compiler refuses to inline the thing because
it's not optimizing, it will still create the function for you).  Most
of them were _changed_ to "extern inline" mostly due to the gcc
documentation.

So Craig, go and look at some of those "extern inline" functions. 
Instead of just spouting crap on the mailing list without obvously never
having even _looked_ at the problem.  All of them are _extremely_
reasonable as far as I can tell - feel free to look for yourself.

The ones that were bitten by the egcs bug (let's just be honest and call
it what it really was) were so small that it would have been completely
unreasonable for any good compiler to not inline them.  They were
essentially two assignments and a copy, they just happened to have the
address-of-label thing in some debugging code (because all other gcc
methods of getting the current PC have been buggy at various points). 

Basically, Craig, just come down from your ivory tower and look at the
code, and I'd be surprised if you didn't agree with me that Linux
"extern inline" usage actually makes sense if you were to just spend a
_small_ amount of time actually looking at it instead of spouting off
without knowing what's up.

		Linus

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 12 Feb 1999 craig@jcb-sc.com wrote:
> 
> >To _me_, "standard C" has not been important at all. I'm _more_ than happy
> >to use gcc extensions, because I think they are worthwhile in the kernel. 
> 
> That means, like I already said, you have to be prepared for a very
> bumpy ride.  You've shown that you have trouble coping with that.

Umm..

I had no problems with gcc features for about six or seven years of Linux
development. These things simply didn't use to happen: despite upgrading
_major_ versions of gcc (when Linux started we were using gcc-1.40), for
those six-seven years there weren't really any changes that I ever had
problems with. 

There were tons of code generation bugs over time, but hey, I _expect_
bugs, and while compiler bugs are sometimes really hard and nasty to find,
I don't complain too much: I report them, and I tell people not to use
certain versions. I may be grumpy for a while because I spent ages looking
at a bug that didn't turn out to be mine, but I never get the feeling that
I should really dislike the compiler people. 

The reason I have been complaining so much lately is that I think that the
egcs development has lost that stability. Again, never mind code
generation bugs, I'm talking about _interface_ stability. I've had much
more problems in the last year than I had in the seven years preceding
this.

This may actually not be due to technical reasons as much as simply due to
a different open development model - it may just be that more people see
"partial" work, and some of that partial work breaks stuff. Fine - I like
open development myself, and I use it. But when somebody complains to _me_
that I broke old interfaces, I consider that a bug unless I have a very
very strong technical reason to tell people that I simply _cannot_ support
some old interface any more. 

In contrast, on this list, when people complain that egcs breaks existing
code, the answer is "shut up and live with it" - and then they Cc: me on
the damn thing. And that's why I get so upset, and why these flame-wars
erupt. 

"Shut up and live with it" is not a way of caring for your customers. And
creating the best compiler in the world is not just about code generation:
it's about supporting the people that use it, too. 

I could change my kernel interfaces and tell people that "shut up,
recompile, and be happy". Trust me, that doesn't work when you have a
serious project that you expect others to be serious about too. I make
_damned_ sure that I don't break binaries, and when I do it by mistake I
have egg on my face and I fess up to screwing up. 

On this list, nobody 'fesses up to screwing up any more. And that's sad. 
It makes the egcs project look less serious, and more like a bunch of
people that just want to play at making a commercial-grade compiler. 

		Linus

Re: kernel-2.2.1-undefined references.

[craig]

>I will provide a link back to this message when it happens later.

I wonder if my email, <199807281536.LAA11100@melange.gnu.org>, is
available on-line anywhere.  It was sent to the egcs-patches and
gcc2 mailing lists back last July.  Looking at it, I realize it's
likely I confused <davem@dm.cobaltmicro.com> with Linus in my
recent posts, that is, thinking it was Linus, not Dave, who was
trying to figure out the `extern inline' stuff.  But I'm not sure
why the info provided at great length to someone, seemingly a
Linux person coordinating with egcs/gcc, didn't actually get back
to Linus before this issue came up yet again.

Looking at the thread, it looks like all that <davem> wanted was
some assurance that this "bug" would someday be fixed, and as long
as he got that, there was no need to bother with all the other
stuff some of us (especially myself) were saying, which has recently
been described as "superfluous" (though it turns out to have been
prophetic, if I understand the sequence of events correctly).

Anyway, it's kind of sad nobody (including me) took serious action,
and that Linus didn't somehow get the info, based on that email
of mine back then, and that I didn't first look it up and simply
re-post it, in its entirety, before going to all the trouble of
explaining things...again....

And, as with this time, I wasn't the only one explaining the reality
of compiler development.  No less than Richard Kenner and Richard
Henderson did some of the explaining back then as well.

So maybe we *will* all go through this again, but hopefully with
pointers to these old messages instead.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> From: craig@jcb-sc.com
> Date: 12 Feb 1999 03:11:18 -0000

> If that's right, this problem will occur again, sooner or later.

Yes, and I can tell you when too.  When the kernel doesn't fit on a
floppy, and they exhaust all compressive techniques, and someone
discovers -Os makes the kernel run faster and that it is smaller,
someone will discover those routines that were inline, are not
anymore.

:-(

Then we can hear the bug reports again and explain that even when you
ask the compiler to inline, with -Os, _sometimes_ the compiler
doesn't.

I will provide a link back to this message when it happens later.

Re: kernel-2.2.1-undefined references.

[craig]

>On 11 Feb 1999 craig@jcb-sc.com wrote:
>> 
>> >"address of a label" is a documented gcc extension, and is NOT covered
>> >by any C standard (pending or accepted) that I know of.
>> 
>> So why are you using it?  Why would you design a product to so
>> completely depend on the correct interaction of a variety of
>> extensions supported by only one compiler out of so many choices
>> on the market?
>
>Are you being stupid or argumentative? 

Actually, I was curious.  Your extreme reaction at gcc not behaving
exactly the way you wanted and as it had in the past suggested
you might not be aware of the implications of using such features,
despite having been (IIRC) burnt by this before.  I was attempting,
among other things, to educate you (and others reading this thread)
as to some of those implications.

But go ahead, cast your aspersions on my motivations for taking time
out of my busy schedule to try to 'splain this stuff to you.  Obviously
a huge waste of time, but I factored that in, figuring *somebody*
out there on the Internet might learn from these discussions.

(I've spent much of my career offering explanations like that.  I'm
almost *never* wrong in those cases, but I have taken a lot of heat
from people who see only the short term.  I remember, over a year ago,
trying to explain to a roomful of numerical engineers why a certain
design being proposed for new Fortran features was actually dangerous,
because instead of causing people to make mistakes 50% of the time,
it would cause them to do so more like .5% of the time, make the
mistakes much harder to detect, and thus lead to more actual errors
in deployed code.  They thought I was crazy to reason that way.  I'm
thinking of sending your recent email to them, since you are a great
example of the sort of person that considers 50% failure *better*
than .5% failure in many cases, and I prefer to engineer products
to accommodate that viewpoint, since I somewhat share it, especially
when it comes to stuff involving man-machine interfaces, like gcc.)

>To _me_, "standard C" has not been important at all. I'm _more_ than happy
>to use gcc extensions, because I think they are worthwhile in the kernel. 

That means, like I already said, you have to be prepared for a very
bumpy ride.  You've shown that you have trouble coping with that.

Please learn to adapt to the reality of what happens when you use
cutting-edge, poorly-tested extensions in a compiler undergoing
rapid development.

>So "address of label" is a documented feature of the only compiler I
>compile the kernel with.  As is "inline". And my argument was that
>_neither_ of those features were mentioned in any C standard ("inline" has
>since been added to the proposed standards) - but they were very much
>mentioned in the gcc documentation.

Oh, I *thought* your argument was that, if any release of gcc did
not support the combination of the features in exactly the way
*you* expected, despite not being documented to do so, that
meant *gcc* broke your code.

>Ergo, ANYBODY who uses "standard conformance" as a reason for supporting
>their argument just needs to think twice. That was my only argument.

Okay.  I must have misread your earlier posts, including the one to
me, which kept saying things like "what are these [gcc/egcs] guys
going to *break* next?" [emphasis added].  I apologize.

>I'm
>just trying to show people how silly it is to say that "oh, the standard
>says that 'inline' is just a hint", when the current C standard says
>nothing of the sort at ALL.

I didn't realize that was *all* you were trying to say.  I *thought*
you were also trying to say that a change to gcc's decision-making
process as to whether to actually inline an "inline" function
constituted a bug in gcc, rather than a bug in code that somehow
depended on the inlining actually happening.

>[ rest of your silly email removed - you seem to be arguing against using 
>  gcc in the first place. I just want to make sure that gcc continues to
>  be usable and good for Linux ]

It would be, if Linux didn't make use of so many extensions, as I
explained earlier, in the portion of my email you call "silly".

IIRC, I've occasionally suggested, on USENET, that Linux shouldn't
depend so much on gcc's peculiar characteristics, in the past.  Though
I'm a big fan of gcc/egcs and GNU software in general, from an
engineering standpoint, keeping Linux at arms' length from gcc-specific
extensions would be better for Linux, and I think it'd be, in the
long run, better for gcc as well, because it'd tend to encourage
more general optimizations in gcc, rather than having Linux rely
so much on hand-coded use of extensions to get faster code.  (That's
a stretch, though, for applications like kernel-code generation,
I realize.)

I guess your only motivation is to make gcc better for Linux, but
not make Linux more robust by lessening its dependencies on
particular code-generation strategies used by any particular
version of gcc.

Me, I'd like to see *both* gcc and Linux be usable and good.

gcc, being an optimizing compiler, will someday simply ignore
some instances of "inline" entirely, and use procedure calls instead,
unless it dies for lack of interest first.  That's because inlining
a procedure does not always make for the most optimal code.

(It's obvious enough why, when `-Os' is specified, since that
means optimize for space.  It's less obvious otherwise, that
avoiding inlining will tend to reduce the Icache footprint
of the generated code sufficiently to actually make it go
faster than if inlining was naively done.)

But the larger problem is that you seem to think that, once
a behavior is observed, it is guaranteed in future versions of
that product, even though not clearly documented.  You would
do well to learn the lesson that this is not true, just as
a good engineer knows that, no matter how many widgets he's
seen exactly .542cm wide, he'd better take seriously the
published specs for them that say ".542cm +/- .005cm" and
not design his product to *assume* exactly .542cm for all
future widgets.

Tolerance isn't just for the political-correctness crowd.  It
has real meaning, and, when properly employed, real value
in engineering, including software design.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[craig]

>and on the whole we'd like to try triggering that sort of thing,

I meant "try *to avoid* triggering", which I hope was obvious.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[craig]

>This whole thread only serves to fill all our mailboxes with a bunch
>of name-calling and nitpicking.  It does not help the development of
>gcc or linux (I assume the reason we are all subscribed to this
>listserv is to _help_ the development of gcc, no?).  It is the
>software development equivalent of ``my dad can beat up your dad!''.

Sorry, I'm not here to play the "let's all get along" game.

If Linus persists in assuming he'll be promised actual inline whenever
he says "inline", he'll continue making Linux *worse*.  If he learns
how to better engineer the code within Linux to at least work within
reasonable tolerances of how gcc extensions behave, he'll make it
*better*.

As I said, this is at least the second time around with him on this
sort of thing.  *He* has chosen to not get along, and to repeatedly
disregard the solid advice he's been given.

>Basically (without all the name-calling), the developers of egcs found
>that combining two gcc extensions did not produce reliable code.  So,
>they took the easy fix: don't allow them to be combined.  This broke a
>significant amount of code for one user, Linus (granted he is not just

As far as I can tell, it broke no *correct* code at all.

>_any_ user, nonetheless ...).  I am sure other people who depend on
>these gcc extensions will also feel the pinch.  This is all fact,
>everything else that has been said is superfluous.

Sorry, I disagree.  Much of what I said, if actually paid attention
to, would help people produce more solid code, and perhaps a more
solid compiler as well.  I don't appreciate being told everything
else I said was "superfluous".  Is this your idea of trying to get
people to stop "name-calling and nitpicking"??

>That being said, is there anything we can do together to improve the
>situation for all of us?  Obviously the combination of these
>extensions worked sometimes.

AFAICT, they still worked, for correct code.  And someday gcc will
outright *ignore* "extern inline" sometimes for even ordinary
functions, because someday it will be an even better optimizing
compiler, which is what it is advertised as (as versus a macro-based
code generator, which is what some people seem to treat it as).

>Is there any way to find out when it
>works and when it doesn't?  It should be a deterministic problem, no?

It was and is working fine, AFAIK.  Bad code that depended on the
generated code having certain undocumented properties stopped working,
and on the whole we'd like to try triggering that sort of thing,
but it's something we can't always prevent, and the world would be
a better place if people who wrote bad code like that took well-
intentioned advice to stop.

>Perhaps Linus has some cases in his code where he knows it works.
>Perhaps other has incidences where it doesn't.  Is there not time to
>address these issues now?  Can it be put on the TODO list?  Can we at
>least agree on how to warn/error when gcc can't comply with what the
>programmer wants?  There has to be something that can be done to make
>the compiler (and the atmosphere on this thread) better.

There apparently already was, -Winline, and it wasn't being used.

The atmosphere on this thread will get better only once Linus retracts
his claims that it was *gcc* that broke *his* code, and accepts
that his code was wrong.

>Admittedly, I have not the knowledge nor the expertise to investigate
>these options myself (I am but a lowly chemical engineer).  I
>apologize for this (my only intention is to help).

I have rarely seen anybody step into an argument in the way you've
done actually succeed at helping.  Playing "good cop" when your
tactics include casting aspersions on the points people like
myself have taken our time to carefully make frankly does *not*
help.

But it sure seems to make some people *think* it helps, and I guess,
these days, that's all that matters.  Kinda like those executives
who felt it was better to "get along" with the folks their company
was contracting for than to tell them bad news about risks involving
their products.

Of course, the result was the Challenger explosion and seven
people killed, but the nice motivation to "get along" was all that
mattered, right?

>Let's turn this thread around, discuss some specifics, and get
>something done.

The buglet in gcc has, I gather, already been fixed.  I haven't
gotten the impression the underlying bug(s) in Linux have, or
will, get fixed.

If that's right, this problem will occur again, sooner or later.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 11:15 PM 2/11/99 -0000, you wrote:
>Obviously the combination of these extensions worked sometimes.
>Is there any way to find out when it works and when it doesn't?
>It should be a deterministic problem, no?

So is the halting problem <g>

[deletia]

Well said. Let's all get along.
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

In message < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu > you write:
> 
> ENOUGH!!!!!!!!!!!
> 
> [deleted]
> 
> Let's turn this thread around, discuss some specifics, and get
> something done.

Already done and in the CVS tree thanks to Richard Henderson.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[David J. Dooling]

   >In article < 19990210133236.30212.qmail@deer >,  <craig@jcb-sc.com> wrote:
   >>>On 9 Feb 1999 craig@jcb-sc.com wrote:
   >>>
   >>>> >Why don't you just remove "inline" completely, then?
   >>>> 
   >>>> Because it works just fine, and as documented, for 99.9999% of the
   >>>> uses to which its put in code compiled by gcc?
   >>>
   >>>Right. So why break it then?
   >>
   >>By your apparent standards, it always *was* broken, because inlining
   >>didn't always happen.
   >
   >No.
   >
   >gcc _did_ use to always inline if it at all could do so.
   
   False.  gcc *never* inlined 100% reliably.  It might have tried,
   and succeeded often enough, but other times, it just generated
   bad code, or ran out of memory, or similar.

ENOUGH!!!!!!!!!!!

This whole thread only serves to fill all our mailboxes with a bunch
of name-calling and nitpicking.  It does not help the development of
gcc or linux (I assume the reason we are all subscribed to this
listserv is to _help_ the development of gcc, no?).  It is the
software development equivalent of ``my dad can beat up your dad!''.

Basically (without all the name-calling), the developers of egcs found
that combining two gcc extensions did not produce reliable code.  So,
they took the easy fix: don't allow them to be combined.  This broke a
significant amount of code for one user, Linus (granted he is not just
_any_ user, nonetheless ...).  I am sure other people who depend on
these gcc extensions will also feel the pinch.  This is all fact,
everything else that has been said is superfluous.

That being said, is there anything we can do together to improve the
situation for all of us?  Obviously the combination of these
extensions worked sometimes.  Is there any way to find out when it
works and when it doesn't?  It should be a deterministic problem, no?
Perhaps Linus has some cases in his code where he knows it works.
Perhaps other has incidences where it doesn't.  Is there not time to
address these issues now?  Can it be put on the TODO list?  Can we at
least agree on how to warn/error when gcc can't comply with what the
programmer wants?  There has to be something that can be done to make
the compiler (and the atmosphere on this thread) better.

Admittedly, I have not the knowledge nor the expertise to investigate
these options myself (I am but a lowly chemical engineer).  I
apologize for this (my only intention is to help).

Let's turn this thread around, discuss some specifics, and get
something done.

DAVID?

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 11 Feb 1999 craig@jcb-sc.com wrote:
> 
> >"address of a label" is a documented gcc extension, and is NOT covered
> >by any C standard (pending or accepted) that I know of.
> 
> So why are you using it?  Why would you design a product to so
> completely depend on the correct interaction of a variety of
> extensions supported by only one compiler out of so many choices
> on the market?

Are you being stupid or argumentative? 

To _me_, "standard C" has not been important at all. I'm _more_ than happy
to use gcc extensions, because I think they are worthwhile in the kernel. 

So "address of label" is a documented feature of the only compiler I
compile the kernel with.  As is "inline". And my argument was that
_neither_ of those features were mentioned in any C standard ("inline" has
since been added to the proposed standards) - but they were very much
mentioned in the gcc documentation.

Ergo, ANYBODY who uses "standard conformance" as a reason for supporting
their argument just needs to think twice. That was my only argument. I'm
just trying to show people how silly it is to say that "oh, the standard
says that 'inline' is just a hint", when the current C standard says
nothing of the sort at ALL.

[ rest of your silly email removed - you seem to be arguing against using 
  gcc in the first place. I just want to make sure that gcc continues to
  be usable and good for Linux ]

		Linus

Re: kernel-2.2.1-undefined references.

[craig]

>In article < 19990210133236.30212.qmail@deer >,  <craig@jcb-sc.com> wrote:
>>>On 9 Feb 1999 craig@jcb-sc.com wrote:
>>>
>>>> >Why don't you just remove "inline" completely, then?
>>>> 
>>>> Because it works just fine, and as documented, for 99.9999% of the
>>>> uses to which its put in code compiled by gcc?
>>>
>>>Right. So why break it then?
>>
>>By your apparent standards, it always *was* broken, because inlining
>>didn't always happen.
>
>No.
>
>gcc _did_ use to always inline if it at all could do so.

False.  gcc *never* inlined 100% reliably.  It might have tried,
and succeeded often enough, but other times, it just generated
bad code, or ran out of memory, or similar.

Exactly what would you do if one of those "reliable" gcc compilers
produced bad code when inlining?  Remember: you do not have the
option of answering "change my code to work around the bug", since
you are complaining about having to change your code to be correct
according to the gcc docs.  So what would you do, that you cannot
possibly cope with doing in the case you are now complaining about?

>There were
>cases that made it unable to inline, simply because the code itself was
>not conducive to inlining.  Those were _technical_ reasons for not
>chosing to inline something, and completely and utterly understandable. 

Yet, you completely and utterly do *not* understand some of the
common-sense reasons for gcc to choose *not* to inline something,
such as "the gcc developers decided generation of bad code was
too likely if a procedure meeting certain criteria was inlined"
and "the gcc developers decided it took too much memory to inline
this sort of procedure in certain circumstances".

Since "inline" is universally understood to be a *suggestion*, not
a *command*, it's not usually rigorously documented in terms of
exactly what conditions guarantee either 100% or 0% actual inlining,
especially not in the sense of a *specification* of the language
being compiled.

I'd be surprised if you could find a *single* compiler in the entire
market that documented *exactly* the criteria under which a procedure
would be guaranteed to be inlined, saying other procedures would
never be inlined.  If you do, please switch to using it instead of
gcc.  (It might be a Forth compiler, for example, so you'd have
to translate Linux into Forth.  You'd probably be happier with the
results.)

>For example, not inlining a recursive function is just obviously the
>right thing to do (yes, in theory you could try to make it iterative,
>but if the programmer gave the compiler a recursive function then it's
>the _programmer_ who is responsible for it, and nobody really expects
>the compiler to do miracles).

*You* do.  You expect the compiler to somehow *know*, all by itself,
with no human intervention, whether it is able to inline a procedure
from first principles and thus *always* produce correct code for any
case where it can be shown that inlining is at all possible.

Either that, or you expect the compiler *developers* to do miracles:
produce a compiler that can inline anything conceptually inlinable,
without ever producing bad code, running out of memory (when *not*
inlining *wouldn't* have), taking too much CPU time (compared to
*not* inlining), etc.

What is seems you're *really* saying, though, is that you prefer
the generation of bad code.  Though it's hard to tell *what*
you're saying, other than "I feel the need to spew at people who
are just trying to do a good job, because they disagree with me
about something regarding which I have little expertise".

For example, you seem to think taking the address of a procedure
makes that procedure uninlinable.  Wrong.  It just does *currently*.
It won't always do so.  I can easily imagine several ordinary,
common constructs that involve taking the address of a procedure
that a much smarter code-generation technology could happily take
into account when inlining.  Same for recursion.

Therefore, all anyone can truly say about "inline" is that it is a
*suggestion*, and guidelines about whether it actually happens are
just those -- guidelines, which can change from release to release,
perhaps even compile to compile.

If you don't want inlining to happen; don't say "inline"; use
whatever compiler options disable inlining; inspect the generated
code to see if inlining happened, and modify the source code
as necessary to avoid it, or modify the generated code and be done
with it.

If you *do* want inlining to happen, same as above, only inverted:
say "inline"; use whatever compiler options enable inlining; inspect
the generated code to see if inlining happened, and modify the
source code as necessary to force it to, or modify the generated
code and be done with it.

In both cases, once you achieve the desired results, throw them out
the next time you compile, regardless of whether you're using the
exact same compiler, source code, etc., but especially if you're
using a new version.

There.  I just stated what I bet *every* compiler vendor of the
industry would say, if pressed, about inlining and similar kinds
of optimizations.  Though gcc might be unique in simplifying some
of the above by offering `-Winline', I would *not* stake my life,
limbs, or property on the assumption that any failure to inline
would result in that warning, because a bug preventing the
warning is just too easy to put into gcc.

>>Yet, as I said, even then, it works just fine, and as documented,
>>for 99.9999% of the uses to which it is put in code compiled by gcc.
>
>No. It used to work for 100% of the caaes gcc could handle.

Again, a false, and useless, statement. Any of the cases gcc could not
handle either it did not inline, or it generated bad code.  I guess
you call generating bad code an example of inlinining being properly
"handled".

Essentially, you're making a case for generating bad code.  It's rather
disturbing to know that the author of the most visible free-software
product prefers bad code to be generated, when given a choice
between that and not inlining as "directed" by the programmer.

>The change broke that.

Your code was broken, AFAICT, and the change brought that to your
attention.  Please, deal with that and stop bugging us, though we
don't mind hearing about collateral changes resulting from bug-fixes,
especially when presented as such.

>It used to be a feature you could depend on.

It was always a feature you should *not* depend on, without using
`-Winline', providing external definitions to go with `extern inline',
or whatever was appropriate.

People who read the documentation *carefully* always understood that.

In that sense, you could and still *can* depend on "inline" working
properly.  That means you have to *use* it properly, which you
clearly haven't been doing.

You really ought to research the extensions you're using more carefully
before using them.  Perhaps you shouldn't be using them at all in a
product like Linux.

>The change broke that.

Again, no, it didn't.  You could always depend on "inline" to be
a *recommendation* that gcc try and inline the procedure, and
that if it couldn't or wouldn't, fine.  The results might or might
not be bad code; if bad code got produced, you could depend on the
gcc authors to try to quickly fix it, perhaps by disabling inlining
under certain circumstances until the underlying problem was fixed.

>Yes, the documentation had hedges to handle the real cases (like
>recursion etc) where inlining just isn't feasible, but the fact that it
>hedged its bets doesn't change the fact that people like me used to be
>able to rely on the compiler to do what it was asked to do.

That's correct.  However, the blame does not fall on gcc, or on gcc
developers.

Guess who's left.

The documentation did *not* say "any procedure meeting criteria X
*will* be inlined" and then expand on criteria X.  It *did* say
something much more like "procedures not meeting criteria X are
examples of those that won't be inlined".  That's a very different
thing.

Even if the documentation had been incorrect, relying so much on
the documentation for a product like gcc is, to put it simply,
rather unwise.  I don't trust documentation much, in general.
I've seen how it's put together.  And I know something about
the language(s) in which it is written, and their propensity for
making it easy for the author to write things readers can
misunderstand.

>If it was a case of "oh, gcc used to have a 50-50 policy on when to
>inline, and the change made that a 40-60 policy", then it would have
>been much more palatable. But it wasn't. It was a case of 100% success
>being turned into "I wonder what the hell they'll break next time
>around". 

In reality, it's a case of "I wonder how many more bugs like this
exist in Linux, which future changes in gcc might expose".

Your repeated claims that this constitutes "breakage" on *our* part
now constitutes an out-and-out lie, and I find it to be highly offensive,
since you've already been *thoroughly* corrected on this matter, yet
continue to state it.

The fact is: *your* code had the bug, not gcc, it was *your* code
that was broken, by relying on "inline" guaranteeing actual inlining.
Period.

That being said, yes, you *should* wonder what we'll break next time
around, given how much you depend on behavior not promised in iron-
clad terms in the documentation, and on the interaction of lots of
extensions, some of which are some combination of poorly documented,
poorly designed, poorly implemented, and rarely tested, even in
isolation.

>Repeatability is good.  Random changes that break existing behaviour for
>no technical reason is bad. 

I agree, but nothing was broken by this change that I've been able to
discern, based on the posts I've read.

In fact, it appears something was fixed.

There was a clear *technical* reason for the change, from what I
understand, and nothing particularly random about it.

That there apparently were collateral *changes* -- not *breakages* --
to generated code due to the fixes is unfortunate, and generally we
try to minimize that sort of thing, as a much-lower-priority thing
to worry about than, say, generating correct code or maintaining
some reasonable degree of performance vs. previous releases
(rougly speaking).

But, those kinds of collateral changes do *not* necessarily constitute
a bug in the end-user sense of the term, not even in the ordinary
sense of the term.  Sometimes, things just change.  Sometimes, these
changes expose previously hidden, broken code elsewhere, as appears
to be the case here.

>>(That's not surprising, since gcc is, generally, based on standards
>>such as ISO C, which presumably make it much clearer that "inline"
>>is, like "register", a mere hint.)
>
>"extern inline" is a documented gcc extension. It may be covered by ISO
>C these days, but it didn't use to be.

My old copy of ANSI C (draft) doesn't even cover `inline'.  So, the
*only* source of information on it was the gcc docs, as it turns out,
unless you want to include drafts of subsequent standards or
something (*none* of which promised the behavior on which you're
depending, I'd guess).

Good engineering means not constructing a large-scale project to
depend on features specific to only one incarnation of a standard,
including its extensions, especially poorly-documented ones.

You'd be smart to stop using gcc-specific extensions in general,
at least to stop using them in so many dizzying combinations.
By "smart" I mean you'd be a better engineer.

If you don't care to be a better engineer, you shouldn't be surprised
when things that used to work fine stop working.  (And if you do
become a true engineer, you'll learn to *expect* that ;-).  Engineering
is, among other things, the science of designing things so they work,
period, AFAIK.  I don't think gcc is very well-engineered in that sense;
it's clear Linux isn't, based on your posts, because innocuous
changes to gcc can, apparently, break it (else you're making a huge
fuss over nothing).  At least the gcc developers seem to agree on
making it, on the whole, better engineered -- they generally know
better than to design it assuming undocumented behavior in underlying
products never changes.

You seem to think everything is black-or-white: do what the programmer
said to do, even if it means generating incorrect code, and, oh
by the way, never generate incorrect code.

Reality is different.  Good engineering means having to come to terms
with reality.

>"address of a label" is a documented gcc extension, and is NOT covered
>by any C standard (pending or accepted) that I know of.

So why are you using it?  Why would you design a product to so
completely depend on the correct interaction of a variety of
extensions supported by only one compiler out of so many choices
on the market?

How many *other* products do you know out there that depend to
a similar degree on the correct interaction of so many gcc
extensions?  Are *their* authors so sensitive to changes in
code generation?  If the answer is "none", then why are you
making *your* code *more* unreliable than the rest of the
industry by so depending?  Is being on the "cutting edge"
that important?  If so, why not *act* like someone who *understands*
what being on the cutting edge *means*?

("Hey, I've driven around this 25mph-posted turn at 80mph for
years now and never skidded out.  *Now* you tell me this stuff
called `black ice' made me skid out and smash up my hugely
expensive car.  It was *your* fault for not making this clear,
you should reimburse me for my car, and make sure this `black ice'
stuff never, ever happens again!")

>As such, the people who brought up "standards" as an argument for
>changing the behaviour are fairly hypocritical: it's a good argument but
>in order to hold water it has to be _relevant_.

I don't know that it isn't relevant or that they're being hypocritical:
my impression is, "inline" *is* covered by drafts of upcoming standards
of some relevance.  But if you didn't read a product document, or even
a standards document, guaranteeing actual inlining in the presence of
"inline" in iron-clad, unambiguous terms, *you* were at fault for
depending on such actual inlining.

The reality is, you're trying to exploit nearly every detail of how a
particular compiler works without understanding what a compiler is, what
it does, how it evolves vis-a-vis the development process, language and
library standardization, and so on.

Please stop doing that.  Stop using compilers, or at least stop using any
extensions they offer and stop relying on any *particular* behavior they
exhibit.  Or, *learn* what compilers are all about, if you have the
10 years or so to spend doing it.

You've gotten *tons* of good, solid advice about the issues involved
from people with far more pertinent expertise than you have developing
operating systems, and have so far done a damn fine job of ignoring it.

If you think the "fixes" to the recent "objectionable" patch will
solve your problems, they won't -- because the underlying problems
are *yours* and thus Linux's, not gcc's.  The problem, or some
problem just like it, *will* occur in the future, and our response
will be basically the same: sincere attempt to minimize collateral
changes while striving, *first and foremost*, to prevent the generation
of bad code.  You Have Been Warned.  Yet Again.

Given that we've gone through this with you in the past (and not
just in the area of compilers, IIRC), I suggest you wean Linux
from depending on gcc at all.  Make it compilable by any ANSI C
compiler, for example.  Then maybe you won't get so upset every
time a fairly trivial change to gcc's code generation occurs, and/or
we won't have to endure your flames.

That would be a heck of a lot more progressive than just deciding to
stick with gcc-2.7.2.1 forever.  But if you want to go that route, it
isn't necessarily a bad decision either, as it'll amount to "nailing
down" the behavior of one crucial component in a much larger, complicated
system (Linux), meaning the developers of the larger system can learn
how to avoid the problems in the nailed-down gcc, which they'll
learn more and more about as time goes on.  (There are disadvantages
to that approach, of course.  You'd be changing your code to work
around known bugs in 2.7.2.1 rather than changing it to better
accommodate ongoing improvements in compiler technology, for example.
In the long run, Linux would end up either coded entirely in `asm'
directives, or running slower than other operating systems that
had fewer lines of code and, probably, more features.)

The decision is yours.  Our viewpoints on this matter will not change,
because they cannot -- if we made you the promises you seem to want,
we'd be lying, in which case we might as well go into politics so
we can get babes and power.  That'd just leave gcc development open
to others who aren't suited for that kind of thing, i.e. the current
situation.  So the only reasonable possibility is for *you* to adapt.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Jeffrey A Law]

  In message < 199902110155.RAA14069@atrus.synopsys.com >you write:
  > so many insults.  The change in question was not "for no good reason", it
  > was an attempt to decrease the virtual memory consumption of gcc (I don't
  > know how much it helped).  If the change has limited value and harms the
  > Linux kernel, that may be a good reason to revert the change.  It has not
  > gone into a release, only a snapshot.
To clarify, the change was not because c++ memory consumption.  It was to fix
a real bug -- imagine what happens if you have label initializers which are
used by indirect jumps and you inline the function.

See execute/980526-1.c

The C++ inline memory changes are still in the queue, they haven't been
installed yet.

jeff

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> And no, very few others are complaining, because the breakage only
> happened when you used two gcc extensions together ("inline" and address
> of a label). Linux is probably the only thing that actually uses a lot of
> the extensions. 

Unfortunately, this makes it more likely that the egcs development will
occasionally break Linux; we just don't have that many test cases for
interaction between gcc extensions.  When these are encountered we'll
just have to fix them.

I think that it's perfectly reasonable to ask that the change that broke
this be reverted enough so that you can get the function in question
inlined again, and I'm sure that folks like Jeff are eager to assist you
with just that.  I only hope that in the future it can be handled without
so many insults.  The change in question was not "for no good reason", it
was an attempt to decrease the virtual memory consumption of gcc (I don't
know how much it helped).  If the change has limited value and harms the
Linux kernel, that may be a good reason to revert the change.  It has not
gone into a release, only a snapshot.

In the future if a change to a snapshot breaks Linux, please report it as
a bug, and I'm sure it will be treated as high priority.  To avoid another
round of flamage, it's best to indicate clearly that the code relies on
GNU extensions, so that the (rather large) group of people whose main
interest is a good compiler for conforming code won't get bent out of
shape and fill the list with "but the standard doesn't guarantee that
you can do that" mailings.

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Wed, 10 Feb 1999, Marc Espie wrote:
>
> You could *at least* acknowledge that you read the original documentation 
> wrong, and that you relied on your interpretation of it...

Would that make you happier?

Yes, I publicly acknowledge that the documentation did not _guarantee_
that "inline" will inline. I've several times mentioned that it makes
perfect sense to not inline in many cases.

My gripe is (and has been) that somebody changed gcc behaviour for no good
reason, and that the behaviour was strongly implied in the documentation. 
Furthermore, all features involved were documented gcc extensions, and
that the Linux usage was in no way unreasonable. The functions in question
were

 (a) very small
 (b) _needed_ to be inlined exactly because they used another gcc feature
     in order to report potential problem locations correctly.
 (c) did not do _anything_ that could reasonably be considered illegal in
     an inline function.

And yes all of it could have been done some other way. The reason Linux
used them as it used them was that all the other portable alternatives
were more broken (I'd have _loved_ to use documented gcc interfaces, but
they didn't actually happen to work). 

And no, very few others are complaining, because the breakage only
happened when you used two gcc extensions together ("inline" and address
of a label). Linux is probably the only thing that actually uses a lot of
the extensions. 

			Linus

Re: kernel-2.2.1-undefined references.

[Marc Espie]

You could *at least* acknowledge that you read the original documentation 
wrong, and that you relied on your interpretation of it...

You have stated repeatedly that egcs broke a *documented* feature, and we
have been repeatedly telling you that it was undocumented, and that your
interpretation was wrong. The *implementation* worked in the way you described,
but the *interface* did not !

Is it *that* hard to state publically ?   Nowhere in *any* of your messages
did you even *hint* that you may have made a small misinterpretation.

Afterwards, we can all go back to serious coding, like getting the documentation
straighter, or fixing egcs to get more compatible with old gcc's ways (which
is *the* current problem. but stop referring to it as `breaking old documented
behavior, which is getting on everybody's nerves, haven't you noticed ? :) )

Get your gripes straight, please. We all know that you have been having trouble
with egcs in the past, this is no reason to be downright insulting to people
who have been *very* responsive to motivated queries, as I can attest from
the OpenBSD side of the free world.

(kuddoes to Mike, Jeff, Kaveh, Zack, and the rest).

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

This response is too long, but it's the last I'll say on the
subject.

In message < 79sgd8$p7p$1@palladium.transmeta.com > you write:
> In article < 19990210133236.30212.qmail@deer >,  <craig@jcb-sc.com> wrote:
> >>On 9 Feb 1999 craig@jcb-sc.com wrote:
> >>
> >>> >Why don't you just remove "inline" completely, then?
> >>> 
> >>> Because it works just fine, and as documented, for 99.9999% of the
> >>> uses to which its put in code compiled by gcc?
> >>
> >>Right. So why break it then?
> >
> >By your apparent standards, it always *was* broken, because inlining
> >didn't always happen.
> 
> No.
> 
> gcc _did_ use to always inline if it at all could do so.  There were
> cases that made it unable to inline, simply because the code itself was
> not conducive to inlining.  Those were _technical_ reasons for not
> chosing to inline something, and completely and utterly understandable. 
> 
> For example, not inlining a recursive function is just obviously the
> right thing to do (yes, in theory you could try to make it iterative,
> but if the programmer gave the compiler a recursive function then it's
> the _programmer_ who is responsible for it, and nobody really expects
> the compiler to do miracles).

And that was the case here.  The problem you faced was *not* due to
any artificial limit arbitrarily imposed by the compiler but a
technical limitation that was discovered in which gcc/egcs was
generating bad code when inlined code used computed jumps.  The test
to disable inlining in this case was casting too wide a net...  See
Richard Henderson's fix:

	http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00172.html

> It used to be a feature you could depend on.
> 
> The change broke that.

This was never a feature you could blindly depend on and -Winline is there
for the simple reason that it can fail when the programmer might not expect
it to. This is a technical issue, and always was.  You were the one who
turned it into some sort of Jihad and started insulting people
(although some of my friends were quite impressed that I had been
personally insulted by Linus Torvalds, I wasn't too fond of it).
For this particular case, the bug/shortcoming has been fixed, but that doesn't
change the fact that the interaction between certain coding structures and
inlining is fragile.  Your mistake was and still is in assuming that it isn't.

> Yes, the documentation had hedges to handle the real cases (like
> recursion etc) where inlining just isn't feasible, but the fact that it
> hedged its bets doesn't change the fact that people like me used to be
> able to rely on the compiler to do what it was asked to do.
> 
> If it was a case of "oh, gcc used to have a 50-50 policy on when to
> inline, and the change made that a 40-60 policy", then it would have
> been much more palatable. But it wasn't. It was a case of 100% success
> being turned into "I wonder what the hell they'll break next time
> around". 
> 
> Repeatability is good.  Random changes that break existing behaviour for
> no technical reason is bad. 

That's where you are mistaken, this was a "real" case.  I'd have to side with
the point of view that says if you can't reliably generate good code then the
best "fix" is to disable the feature.  That was the case here, the only
problem was that *you* weren't prepared to recognize and deal with the
failure.  If, in the future, egcs developers discover that label
addresses cause bad code to be generated in many circumstances, then
that alone would justify turning off inlining in their presence, even
if those don't include the ones you are relying one.  Ideally, bugs
get fixed, but you know as well as I that sometimes they just get
papered over until they are fixed.  You do the same thing, I've seen
it in action.  Don't impugn the motives of other developers for that.

Get over it.  EGCS *is* a very reliable compiler, but one under very
active development.  Backwards compatibility has *never*, to my
knowledge, been gratuitously broken.  There have been bugs that made
it fail and there have been incompatibilities justified by sound technical
reasoning.

The problem here was primarily with your reliance on a particular
interpretation of a feature which is documented to be unreliable.  If
a previous version of the compiler permitted a use which leads to
broken code (inlining with computed gotos), then there was sound
technical reason to disable it.  And that should be as obvious to you
as anyone else.  The fact that you went off half cocked without even
seeking an explanation doesn't reflect very well on you.  And neither
does your insulting everyone who has disagreed with you.

Time for all of us to get back to coding.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Joe Buck]

[ __builtin_constant_p ]

> It works in development versions of egcs, but as far as I know of it does
> not work in _any_ released version of gcc. It certainly is not something
> you can really use anyway, as using it requires that all users have to
> upgrade: which may be acceptable in some environments, but is certainly
> not an option in most places.

If the feature gives a clear win, it is possible to use it with a
preprocessor check.  To oversimplify a bit:

#if __GNUC_MINOR__ > threshold
... code using the feature
#else
... older code
#endif

Since this conditional compilation gives one more thing to test for, the
developers might choose not to use it unless the win is large enough
to justify it.

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Wed, 10 Feb 1999, Jamie Lokier wrote:

> Jamie Lokier wrote:
> > H. Peter Anvin wrote:
> > > Oh yes, __builtin_constant_p() really, really ought to work properly
> > > in an inline...
> > 
> > It does.  See egcs-1.0.3.
> 
> Bugger, I was wrong.  Sorry Peter.

It works in development versions of egcs, but as far as I know of it does
not work in _any_ released version of gcc. It certainly is not something
you can really use anyway, as using it requires that all users have to
upgrade: which may be acceptable in some environments, but is certainly
not an option in most places.

The same is true of certain other features like __builtin_return_address() 
(which _does_ work in egcs-1.0.3 I've been told, but doesn't work in many
other versions) which makes them essentially a non-issue in production
environments with multiple versions of gcc. It's good that these things
evolve and get fixed, but the fact that they have gotten fixed does NOT
mean that people can just start depending on them - that will happen much
much later. 

This is one reason why it's so important to _not_ break backwards
compatibility if at all possible: even if you introduce a new feature that
makes an old feature unnecessary, you can't just force all your users to
upgrade overnight, and you should expect people to use old and new
versions concurrently - so the old feature has to stay (not forever, but
certainly for at least one major release - which for most bigger projects
implies at least a year of "migration time"). 

No, I don't enjoy it either. Maintenance is not especially exciting or
interesting, but it _is_ important. Expect people to rely on
__builtin_constant_p inside inline functions in another two years or so.

		Linus

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

In article < 19990210133236.30212.qmail@deer >,  <craig@jcb-sc.com> wrote:
>>On 9 Feb 1999 craig@jcb-sc.com wrote:
>>
>>> >Why don't you just remove "inline" completely, then?
>>> 
>>> Because it works just fine, and as documented, for 99.9999% of the
>>> uses to which its put in code compiled by gcc?
>>
>>Right. So why break it then?
>
>By your apparent standards, it always *was* broken, because inlining
>didn't always happen.

No.

gcc _did_ use to always inline if it at all could do so.  There were
cases that made it unable to inline, simply because the code itself was
not conducive to inlining.  Those were _technical_ reasons for not
chosing to inline something, and completely and utterly understandable. 

For example, not inlining a recursive function is just obviously the
right thing to do (yes, in theory you could try to make it iterative,
but if the programmer gave the compiler a recursive function then it's
the _programmer_ who is responsible for it, and nobody really expects
the compiler to do miracles).

>Yet, as I said, even then, it works just fine, and as documented,
>for 99.9999% of the uses to which it is put in code compiled by gcc.

No. It used to work for 100% of the caaes gcc could handle.

The change broke that.

It used to be a feature you could depend on.

The change broke that.

Yes, the documentation had hedges to handle the real cases (like
recursion etc) where inlining just isn't feasible, but the fact that it
hedged its bets doesn't change the fact that people like me used to be
able to rely on the compiler to do what it was asked to do.

If it was a case of "oh, gcc used to have a 50-50 policy on when to
inline, and the change made that a 40-60 policy", then it would have
been much more palatable. But it wasn't. It was a case of 100% success
being turned into "I wonder what the hell they'll break next time
around". 

Repeatability is good.  Random changes that break existing behaviour for
no technical reason is bad. 

>(That's not surprising, since gcc is, generally, based on standards
>such as ISO C, which presumably make it much clearer that "inline"
>is, like "register", a mere hint.)

"extern inline" is a documented gcc extension. It may be covered by ISO
C these days, but it didn't use to be.

"address of a label" is a documented gcc extension, and is NOT covered
by any C standard (pending or accepted) that I know of.

As such, the people who brought up "standards" as an argument for
changing the behaviour are fairly hypocritical: it's a good argument but
in order to hold water it has to be _relevant_. 

		Linus

Re: kernel-2.2.1-undefined references.

[Jamie Lokier]

Jamie Lokier wrote:
> H. Peter Anvin wrote:
> > Oh yes, __builtin_constant_p() really, really ought to work properly
> > in an inline...
> 
> It does.  See egcs-1.0.3.

Bugger, I was wrong.  Sorry Peter.

I was _told_ it is working in some EGCS version, and misread a test I
did earlier.  It ought to be working by now: I submitted a patch a very
long time ago, and was told something similar had been installed into
the tree.

-- Jamie

Re: kernel-2.2.1-undefined references.

[craig]

>On 9 Feb 1999 craig@jcb-sc.com wrote:
>
>> >Why don't you just remove "inline" completely, then?
>> 
>> Because it works just fine, and as documented, for 99.9999% of the
>> uses to which its put in code compiled by gcc?
>
>Right. So why break it then?

By your apparent standards, it always *was* broken, because inlining
didn't always happen.

Yet, as I said, even then, it works just fine, and as documented,
for 99.9999% of the uses to which it is put in code compiled by gcc.

(That's not surprising, since gcc is, generally, based on standards
such as ISO C, which presumably make it much clearer that "inline"
is, like "register", a mere hint.)

Sorry you recently got bit by this, though.  That happens quite often
when using tools as complex as gcc, I'm afraid -- review all the
egcs- and gcc2-related discussions regarding 64-bit alignment of
REAL*8 (aka `double') on PPro and PII chips that have gone on
even since we *thought* we had this "fixed" in a long-ago version
of g77 based on gcc 2.7.something.  As with your situation, what
we thought "worked" just happened to not fail, and getting it
to truly work properly is much more difficult, politically as well as
technically, than we ever thought.

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Theodore Papadopoulo]

Matthias Urlichs:
> The current limiting code was, AFAIK, put in because excessive inlining
> caused egcs (more specifically, g++) to require a somewhat ugly amount of
> swap space. But somebody else can probably answer that question better than
> me.

	No, to my knowledge the patch that limits the size of inlined 
function is not yet in the egcs sources. The current source still 
does not limit the size of function marked as inline (I guess that 
extern inline functions are treated the same way). Note that function 
not marked as inline can be inlined by the compiler and that there is 
a size limit for those (but that's not the case discussed in this 
thread).

AFAICT, the patch has not yet incorporated precisely because of concerns about:
- having understandable rules (how the limit is expressed and when it 
  is in effect.
- breaking the current behaviour of gcc as little as possible.

This is clearly an example showing that egcs people are not changing 
things without being convinced that they do the right thing.

The discussion thread subject was "g++ memory bug" for those that are 
interested.

The current list of reasons for which a function would not be inlined
has been given by Richard Henderson in a previous message of this 
thread.

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: kernel-2.2.1-undefined references.

[Matthias Urlichs]

Hi,

Linus Torvalds:
> If you guys even had a _technical_ reason for changing things, I'd
> understand. As it is, I really don't look forward to working with people
> who want to change compiler interfaces on a day-to-day basis.
> 
The current limiting code was, AFAIK, put in because excessive inlining
caused egcs (more specifically, g++) to require a somewhat ugly amount of
swap space. But somebody else can probably answer that question better than
me.

Anyway, it's been documented for some time that inline isn't always
honored. Whether that happens in 10% or in 0.0001% of the cases which are
relevant for the Linux kernel is, IMHO, somewhat non-interesting.

Anyway^2, fixing the problem is easy, all we need to do is to decide on a
"correct" way to do it. (Famous last words, I know. On the other hand,
neither 'side' of this debate needs the ego boost provided by Having Been
Right All Along, so...)

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
I haven't got time to chat to undersecretaries, permanent or otherwise.
                                -- Pertwee, DOCTOR WHO AND THE SILURIANS

Re: kernel-2.2.1-undefined references.

[Jamie Lokier]

H. Peter Anvin wrote:
> Oh yes, __builtin_constant_p() really, really ought to work properly
> in an inline...

It does.  See egcs-1.0.3.

-- Jamie

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 9 Feb 1999 craig@jcb-sc.com wrote:

> >Why don't you just remove "inline" completely, then?
> 
> Because it works just fine, and as documented, for 99.9999% of the
> uses to which its put in code compiled by gcc?

Right. So why break it then?

		Linus

Re: kernel-2.2.1-undefined references.

[craig]

>Why don't you just remove "inline" completely, then?

Because it works just fine, and as documented, for 99.9999% of the
uses to which its put in code compiled by gcc?

        tq vm, (burley)

Re: kernel-2.2.1-undefined references.

[Marc Espie]

In article < Pine.LNX.3.95.990208183457.433I-100000@penguin.transmeta.com > you write:

>In particular, "extern inline" has basically been documented to be a macro
>(some Clintonesque arguments to the contrary notwithstanding), and does
>not make sense to not inline - the documentation even says so. If I have
>to add an "extern" to force the inline, that's fine.

I'm sorry but this is bullshit. Read the fucking manual. I even took the time
to research gcc 2.7.2' extend.texi. Is that old enough for you ?
I have included the whole node of the documentation *here* so that you can't
accuse me of trying to finnagle my way out of a tight place...

------------------------
| @section An Inline Function is As Fast As a Macro
| @cindex inline functions
| @cindex integrating function code
| @cindex open coding
| @cindex macros, inline alternative
| 
| By declaring a function @code{inline}, you can direct GNU CC to
| integrate that function's code into the code for its callers.  This
| makes execution faster by eliminating the function-call overhead; in
| addition, if any of the actual argument values are constant, their known
| values may permit simplifications at compile time so that not all of the
| inline function's code needs to be included.  The effect on code size is
| less predictable; object code may be larger or smaller with function
| inlining, depending on the particular case.  Inlining of functions is an
| optimization and it really ``works'' only in optimizing compilation.  If
| you don't use @samp{-O}, no function is really inline.

First point, inlining is an optimization. As far as I know, optimizations
are fine-tuning, that should be termed as not changing semantics.

| To declare a function inline, use the @code{inline} keyword in its
| declaration, like this:
| 
| @example
| inline int
| inc (int *a)
| @{
|   (*a)++;
| @}
| @end example
| 
| (If you are writing a header file to be included in ANSI C programs, write
| @code{__inline__} instead of @code{inline}.  @xref{Alternate Keywords}.)

| You can also make all ``simple enough'' functions inline with the option
| @samp{-finline-functions}.  Note that certain usages in a function
| definition can make it unsuitable for inline substitution.

*WHAT* is not clear in the preceding paragraph ?  Stuff covered
by `certain usages in a function definition' is obviously very vague,
but the intent is not: inlining is an *optimization*. The compiler had better
do its damned best to implement it, but it has *no obligation* to inline
functions.

| Note that in C and Objective C, unlike C++, the @code{inline} keyword
| does not affect the linkage of the function.

| @cindex automatic @code{inline} for C++ member fns
| @cindex @code{inline} automatic for C++ member fns
| @cindex member fns, automatically @code{inline}
| @cindex C++ member fns, automatically @code{inline}
| GNU CC automatically inlines member functions defined within the class
| body of C++ programs even if they are not explicitly declared
| @code{inline}.  (You can override this with @samp{-fno-default-inline};
| @pxref{C++ Dialect Options,,Options Controlling C++ Dialect}.)

| @cindex inline functions, omission of
| When a function is both inline and @code{static}, if all calls to the
| function are integrated into the caller, and the function's address is
| never used, then the function's own assembler code is never referenced.
| In this case, GNU CC does not actually output assembler code for the
| function, unless you specify the option @samp{-fkeep-inline-functions}.
| Some calls cannot be integrated for various reasons (in particular,
| calls that precede the function's definition cannot be integrated, and
| neither can recursive calls within the definition).  If there is a
| nonintegrated call, then the function is compiled to assembler code as
| usual.  The function must also be compiled as usual if the program
| refers to its address, because that can't be inlined.
| 
| @cindex non-static inline function
| When an inline function is not @code{static}, then the compiler must assume
| that there may be calls from other source files; since a global symbol can
| be defined only once in any program, the function must not be defined in
| the other source files, so the calls therein cannot be integrated.
| Therefore, a non-@code{static} inline function is always compiled on its
| own in the usual fashion.
| 
| If you specify both @code{inline} and @code{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.

| This combination of @code{inline} and @code{extern} has almost the
                                                          ^^^^^^
| effect of a macro.  The way to use it is to put a function definition in
| a header file with these keywords, and put another copy of the
| definition (lacking @code{inline} and @code{extern}) in a library file.
| The definition in the header file will cause most calls to the function
                                               ^^^^
| to be inlined.  If any uses of the function remain, they will refer to
| the single copy in the library.

I fail to see what's unclear about the preceding paragraph. The intent
is clear, code design is clear (why would you want to provide a library
definition for extern inline, except for the fact that not all calls are
guaranteed to be inlined).

| GNU C does not inline any functions when not optimizing.  It is not
| clear whether it is better to inline or not, in this case, but we found
| that a correct implementation when not optimizing was difficult.  So we
| did the easy thing, and turned it off.
| 

>Removing features without giving a reasonable way of doing the thing that
>gcc has successfully been doing for 8 years is not reasonable.

You can make a case for *changing* the documentation, you can say that 
egcs current is breaking your code, but the feature you're asking is
basically undocumented.  Heck, this old piece of evidence, which has not
changed thru gcc 2.8.1, and now egcs, contradicts your ranting.

>Codifying the fact that if you really _rely_ on inlines, do so with an
>"extern inline" is ok would be very reasonable. Maybe you could even say
>that "extern inline" is honoured even when not optimizing.

Documentation *explicitly* says otherwise. Documentation *explicitly* tells
you that you should not _rely_ on extern inline exclusively.

>> I prefer to follow the standard where it says that inline is a hint,
>> and only a hint.
>
>You also seem to prefer breaking documented behaviour.

Undocumented.

Now, don't get me wrong. I perfectly agree with you that it would be better
if egcs were able to inline the same functions (and more) than gcc used
to be able to. This is your way of asking that gets on my nerves.

Breaking compilers gratuitously is probably something the egcs folks are
not doing. They're trying hard to do a good job, and there are compromises
sometimes that need to be done.   The current documentation shows some
leeway for the compiler implementor. Changing slightly actually inlined 
functions does not contradict the documentation. Hell, it should not even
break code (apart from performance), or else, blech. There are some parts
of the Linux kernel I *don't* want to touch.

>You also seem to want to ignore the knowledgeable user that knows, for
>example, that yes, this is a frigging big inline, but it's only used in
>one place, and it's inline in order to make the code more readable, but I
>really want to have the compiler inline it for me to make the code faster. 

>Why not just say that for "extern inline" there are NO artifical limits,
>because the damn documentation _tells_ you that "extern inline" is a gcc
>extension to the language that creates a macro-like function. 

>Instead of breaking stuff that used to work. 

Well, telling it another way, you got bitten by non-portable code...

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On 9 Feb 1999, Nick Burrett wrote:
> 
> You could always just fix your code.

"change", not "fix". The code is correct, and has been correct for a long
time.

Yes, I could.

But where the hell does it all end? Do I every other month have to make
changes to the kernel because the compiler keeps changing normal
interfaces? What is to say that some "bright" person isn't going to make
other changes to how inline works, and disallow some other random feature
for no technical reason.

If you guys even had a _technical_ reason for changing things, I'd
understand. As it is, I really don't look forward to working with people
who want to change compiler interfaces on a day-to-day basis.

That's like me changing system call behaviour without testing whether old
applications still work.

"Oh, it's not really specified by POSIX, so the fact that it's been done
by people that way for eight years doesn't matter, I want to change it
because I feel like it".

>				In the case of 'skb_put' and 'skb_push'
> gcc will inline the function if you remove the offending if statement.

There is no "offending" statement that I see. Every single thing in the
thing is standard C with regular, documented GCC extensions. 

> Perhaps you should find a better way to obtain the current value of the
> program counter. Why not create a macro, say CURPC, that obtains the current
> value of the program counter in an architecture dependent manner e.g. by
> using an asm() statement ?

Ehh, even better: I could make "skb_over_panic()" be a function that looks
up the return address with __builtin_return_address(0), and then I
wouldn't need to worry at all, right?

Except for the fact that __builtin_return_address() is (a) not really
documented, or at least it didn't use to be and (b) doesn't work with most
gcc versions out there. Richard has fixed it in the current egcs tree, but
that's pretty recent. 

> If you don't want to use an asm() statement then create a small assembler
> function to get your program counter. The overhead is insignificant considering
> you are only going to emit a kernel panic anyway.

The overhead of working with a compiler that doesn't change daily for no
technical reason would be even less significant. 

		Linus

Re: kernel-2.2.1-undefined references.

[Joern Rennecke]

> fixed, what is the difference between register and inline?  Look were
> register is today, totally ignored and totally meaningless.  inline is
> becoming much the same sort of thing, and we don't give hard errors if
> register fails, never have never will.  For consistency, inline should
> behave in a similar fashion.

Well, we do giv an error if register ... __asm__ fails.
It looks like Linus is looking for something similar for inline -
inline this, no matter if the semantics go haywire, I know what I'm doing.
__asm__ inline or inline __asm__, perhaps?

Re: kernel-2.2.1-undefined references.

[Patrick Grueger microTOOL]

>In that case, could there not be a magical Linus-Special Inline
>such as __inline or otherwise, that'd be Just Like inline, but 
>Better(tm)?
like __forceinline in MSDev6.0;-)

Re: kernel-2.2.1-undefined references.

[Gerald Pfeifer]

On Tue, 9 Feb 1999, Paul Derbyshire wrote:
> At 07:20 PM 2/8/99 -0800, you wrote:
>>  The way to use it is to put a function definition in a header file
>>  with these keywords, and put another copy of the definition (lacking
>>  @code{inline} and @code{extern}) in a library file.
> *ahem* There are some of us with mail clients that don't know how to
> render email with these formatting codes. (What is it anyways?

It is texinfo, the format most gcc docs are written in. Just check out
the *.texi in your egcs distribution. As this is a technical list, source
for sure is appropriate.

> Holy sh!t ... er... Is that really Linus Torvalds himself?

<rant>Come one, that guy is not holy nor extraterrestial. What's
the purpose of posting that to the list?</rant>

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: kernel-2.2.1-undefined references.

[Matthias Urlichs]

Hi,

Paul Derbyshire:
> >  @code{inline} and @code{extern}) in a library file.
> 
> *ahem* There are some of us with mail clients that don't know how to render
> email with these formatting codes. (What is it anyways?

Texinfo. I've suffered from the same disease myself; after writing on a
largish .pod file all day, the habit to B<boldface> and I<italicize> and
C<code>ize carries over to email.  :-/

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
Anything not worth doing is not worth doing well.
                                       -- G. Bell

Re: kernel-2.2.1-undefined references

[Mark M. Kettenis]

   Joe Buck (jbuck@Synopsys.COM) wrote:

   It might be appropriate to generate an error, not a warning, if
   "extern inline" fails to inline, since it is clear from the documentation
   that this is not a mere hint.

I may be quoting you out of context, but if you really are suggesting
that failing to inline an ``extern inline'' function should generate
an error (or even a warning without explicitely asking about warnings)
please think again.

The gcc documentation contains the following paragraph:

      This combination of `inline' and `extern' has almost the effect of a
   macro.  The way to use it is to put a function definition in a header
   file with these keywords, and put another copy of the definition
   (lacking `inline' and `extern') in a library file.  The definition in
   the header file will cause most calls to the function to be inlined.
   If any uses of the function remain, they will refer to the single copy
   in the library.

This is exactly how we use ``extern inline'' in the GNU C Library and
the Hurd.  Since even some of the standard ANSI C headers contain
``extern inline'' function (of course properly marked as extensions
and only if gcc/egcs is used) generating errors could possibly make
compiling almost any program impossible, and generating warnings would
be pretty annoying.

The documentation on ``extern inline'' may not be entirely clear, but
the above paragraph is crystal clear.  ``extern inline'' is a hint,
and not providing an additional definition without `inline' and
`extern', is asking for trouble.

Re: kernel-2.2.1-undefined references.

[Paul Derbyshire]

At 07:20 PM 2/8/99 -0800, you wrote:
>  The way to use it is to put a function definition in a header file
>  with these keywords, and put another copy of the definition (lacking
>  @code{inline} and @code{extern}) in a library file.

*ahem* There are some of us with mail clients that don't know how to render
email with these formatting codes. (What is it anyways? It's not HTML or
RTF since my client will render those and it didn't render *those*... and I
know HTML anyways...)

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> That's fine. I'm actually not asking that _all_ "inline" keywords actually
> be honoured, I'm asking that there be some way of forcing gcc to honour
> it, the way it used to do. 

You are still making one incorrect assumption: that you previously had
a guarantee that the compiler would always successfully inline an "extern
inline" function.  You didn't: any version of gcc you care to name would
fail to inline some functions.

> Codifying the fact that if you really _rely_ on inlines, do so with an
> "extern inline" is ok would be very reasonable. Maybe you could even say
> that "extern inline" is honoured even when not optimizing.

Given the current state of things, extern inline could either inline the
function or "die trying".   However, once some standards document says
extern inline means something different, someone will have to suffer:
either every C user (can't give them a correct compiler), or the kernel
developers (we'll have to tell them a new way of forcing "inline").

> Why not just say that for "extern inline" there are NO artifical limits,
> because the damn documentation _tells_ you that "extern inline" is a gcc
> extension to the language that creates a macro-like function. 

Why not just say that the Linux kernel fits in 1 Meg no matter how many
devices or features you have?  After all, it used to.  It would be nice.

The compiler can do its best to inline the function.  But it cannot
promise to do the impossible.

Re: kernel-2.2.1-undefined references.

[TTK Ciar]

  Wow .. can't we all just get along?  It wouldn't be difficult to 
add a command line option to enable the desired (and justifiable) 
behaviour and call it quits.  Tweaking the code in rest_of_compilation 
in toplev.c that calls function_cannot_inline_p() would get us half
way there.  Depending on how exactly it was tweaked, the other half 
of the way might be a little painful, though.  If all you want is for
nonzero function_cannot_inline_p() results (which are in fact verbose 
textual descriptions of the problem -- grep for "cannot be inline" in
integrate.c) to be returned as errors, well, that's really trivial.

  One of the supposed advantages of free software is flexibility and
the ability to give skilled users the control they need over their 
tools.  I'd hate to think we're losing that.

  That being said, I think the current behaviour (ie, silently
dismissing a request to inline) should remain the default compiler 
behaviour just because there are a lot of users who have come to 
rely on this behaviour to fix their broken code, and I don't want
to put up with the screamed ravings of ten thousand incompetent 
programmers when the alternative is to add a switch in our CFLAGS.

  Huge disclaimer:  The above is my opinion only, and has nothing
to do with the official position of Cygnus (if it has one).  I have
little or no influence in getting such a change accepted by the code
maintainers, who might find it objectionable simply because they 
find creeping featurism undesirable.

  -- TTK 

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> Date: Mon, 8 Feb 1999 18:42:53 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>

> Removing features without giving a reasonable way of doing the thing
> that gcc has successfully been doing for 8 years is not reasonable.

Actually, my guess is that someone reported a bug, and someone
investigated it and found that two orthoganal features that seem like
they should work together just fine, in fact didn't and that codegen
correctness was comprimised by the combination and that because of
this, the combination was disabled because the bug fixer didn't have
time to extend the implementation to handle the combination.  I have
done this myself with complex cases of exception regions and inlining.

I hate to even respond to this, because I don't know for certain this
is the exact case at hand.  I hope someone with the knowledge can
confirm it.

Now, I hate that you got hit by a bug fix like this, but if this is
the case, I think it is better to break your code than have the
compiler generate wrong code, even though it may have been doing it
for 8 years.

> Codifying the fact that if you really _rely_ on inlines

I am sorry, don't do that.  :-(

> You also seem to prefer breaking documented behaviour.

To me, the phrases `Note that certain usages in a function definition
can make it unsuitable for inline substitution.'  and `Inlining of
functions is an optimization and it really ``works'' only in
optimizing compilation.' and `Some calls cannot be integrated for
various reasons' I think clearly set the users expectation
appropriately.  If you can suggest wording that would have been
clearer to you, we can fix the document.

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> From: Joe Buck <jbuck@Synopsys.COM>
> To: leei@ai.sri.com (Lee Iverson)
> Date: Mon, 8 Feb 99 17:40:44 PST
> Cc: jbuck@Synopsys.COM, torvalds@transmeta.com, ross.s@ihug.co.nz,
>         egcs@cygnus.com, hpa@transmeta.com

> It might be appropriate to generate an error, not a warning, if
> "extern inline" fails to inline, since it is clear from the
> documentation that this is not a mere hint.

No, it is not appropriate.  First, from the doc:

  The way to use it is to put a function definition in a header file
  with these keywords, and put another copy of the definition (lacking
  @code{inline} and @code{extern}) in a library file.  The definition
  in the header file will cause most calls to the function to be
  inlined.  If any uses of the function remain, they will refer to the
  single copy in the library.

This clearly states that we expect some uses won't use the extern
inline, what would be the point of putting in a library definition if
we got errors on all translation units that didn't inline?

Second, we want forward compatibility with the next ANSI standard for
C, that in that standard, inline will be a pure hint (or if not that
one, in the one after it).  An error message is a motion in the wrong
direction and a motion in the wrong direction is bad.

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> I'm not trying to be unreasonable. I'm just saying that if there is
> a function that is marked inline that can be inlined,

And the case in question is a case where it can't be inlined.  It
isn't that the compiler wants to screw you.  It is just a case where
it is too dumb to comply.

As to the documentation, it clearly states:

  Inlining of functions is an optimization and it really ``works'' only
  in optimizing compilation.  If you don't use @samp{-O}, no function is
  really inline.
  
  Some calls cannot be integrated for various reasons (in particular,
  calls that precede the function's definition cannot be integrated, and
  neither can recursive calls within the definition).
  
  The definition in the header file will cause most calls to the
  function to be inlined.

I don't know how people misread the above.  I find it very clear.  It
says `most' calls will be inlined, not all calls.  It says some can't
be integrated for various reasons, but doesn't say what those reasons
are.  It says that it is only an optimization, not a required
semantic.

What does the phrase `Some calls cannot be integrated for various
reasons' mean to you?  Do you interpret this as a guarantee that gcc
will always inline for you?

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Mike Stump wrote:

> > Date: Mon, 8 Feb 1999 12:15:40 -0800 (PST)
> > From: Linus Torvalds <torvalds@transmeta.com>
> 
> > I'm not trying to be unreasonable. I'm just saying that if there is
> > a function that is marked inline that can be inlined, it _should_ be
> > inlined, because the compiler _never_ knows better than the
> > programmer.
> 
> Let me provide a counterpoint.  In C++, it is common to have
> templates.  In templates, it is common to have lots of small,
> sometimes, really small functions.  Sometimes, programmers put
> `inline' on them.  The C++ standard says they `inline' by default on
> those defined in the class body, this also is common.

That's fine. I'm actually not asking that _all_ "inline" keywords actually
be honoured, I'm asking that there be some way of forcing gcc to honour
it, the way it used to do. 

In particular, "extern inline" has basically been documented to be a macro
(some Clintonesque arguments to the contrary notwithstanding), and does
not make sense to not inline - the documentation even says so. If I have
to add an "extern" to force the inline, that's fine.

Removing features without giving a reasonable way of doing the thing that
gcc has successfully been doing for 8 years is not reasonable.

Codifying the fact that if you really _rely_ on inlines, do so with an
"extern inline" is ok would be very reasonable. Maybe you could even say
that "extern inline" is honoured even when not optimizing.

> I prefer to follow the standard where it says that inline is a hint,
> and only a hint.

You also seem to prefer breaking documented behaviour.

You also seem to want to ignore the knowledgeable user that knows, for
example, that yes, this is a frigging big inline, but it's only used in
one place, and it's inline in order to make the code more readable, but I
really want to have the compiler inline it for me to make the code faster. 

Why not just say that for "extern inline" there are NO artifical limits,
because the damn documentation _tells_ you that "extern inline" is a gcc
extension to the language that creates a macro-like function. 

Instead of breaking stuff that used to work. 

		Linus

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> Date: Mon, 8 Feb 1999 12:15:40 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>

> I'm not trying to be unreasonable. I'm just saying that if there is
> a function that is marked inline that can be inlined, it _should_ be
> inlined, because the compiler _never_ knows better than the
> programmer.

Let me provide a counterpoint.  In C++, it is common to have
templates.  In templates, it is common to have lots of small,
sometimes, really small functions.  Sometimes, programmers put
`inline' on them.  The C++ standard says they `inline' by default on
those defined in the class body, this also is common.

Now, if you put all of that into a complex piece of software, you wind
up with cases where, the compiler wants to consume 10 terabytes of
swap space trying to fulfill the users desire to inline.  Yes, I am
not marking this up, it happens (see a user bug report from use a few
months ago for this exact case).  We have a choice, require they
change their source code (not an opnion, it looks quite nice already),
require they buy 10 terabytes of swap (only $216k, so why not?), don't
compile their code and tell them to go out and buy a better compiler,
or stop inlining just for C++ (I don't like random divergence), or
require they not put inline on things or define them in the class body
or violate the users expectations set from the standard for C++.

Which do you prefer?

I prefer to follow the standard where it says that inline is a hint,
and only a hint.  I have submitted patches to artificially limit the
size of functions that can be inlines to some random size that was
meant to be big enough, so that it would be faster in the typical case
(due to caching effects), than if there were no limit, and so that the
code would even compile.  The limit was something like 6400
instructions.  I tried to pick it so that if everything fit in the
cache, performance would still be within 1% or so of perfect.

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Lee Iverson wrote:
> 
> I actually did, and while the discussion of "extern inline" strongly
> implies that it is guaranteed behavior, it doesn't *really* come out
> and say it.  There is a hedge above though in the sentence "Note that
> certain usages in a function definition can make it unsuitable for
> inline substitution."  It looks like that is just a hedge on automatic
> inlining, but it is really a hedge on the whole process...

And while you're at it, what's your definition for "sex"?

It's ugly in politics, it's ugly in technican discussions. Don't hide
behind technicalities.

		Linus

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Joe Buck wrote:
> 
> Hmm.  Linus does seem to have a point here.  See the node "Inline"
> in the gcc manual.

Thank you. Exactly.

This is not about "what would we do if we redesigned the language". This
is about existing users that have used behaviour and documentation that
has been stable for at least the 8 years I've used gcc, and are extremely
irritated at some willy-nilly changes that break existing documented usage
for no apparent technical reason.

		Linus

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> > Remember, we are not talking about ISO C++ here.  We are talking about
> > *C*, and specifically the GNU "extern inline" extension.  So the M to R
> > is the gcc manual.
> 
> I actually did, and while the discussion of "extern inline" strongly
> implies that it is guaranteed behavior, it doesn't *really* come out
> and say it.  There is a hedge above though in the sentence "Note that
> certain usages in a function definition can make it unsuitable for
> inline substitution."  It looks like that is just a hedge on automatic
> inlining, but it is really a hedge on the whole process...

Yes, clearly some functions cannot be inlined.  The compiler developers
cannot promise the impossible.

The language implies that if inlining fails you'd just have an external
reference, meaning you'd have an undefined symbol if there is not a
second, non-inline definition.

> I do think that the language is ambiguous and definitely suggests
> something that the compiler cannot guarantee.  That's why I've
> submitted a patch to egcs-patches to clarify this:
> 
> 	  http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00176.html

It might be appropriate to generate an error, not a warning, if
"extern inline" fails to inline, since it is clear from the documentation
that this is not a mere hint.

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> No, I heard more than that. Such as, the compiler may opt to make a function
> into an inline based on optimization. Which scares the hell out of me, too.

Get used to it; almost every compiler will do this at high levels of
optimization.

> The argument, though, should be telling you that basing a C compiler
> front-end on top of a C++ engine is going to become more and more risky.

It has nothing to do with C++.  Fortran compilers are the most aggressive
at doing major restructuring of this form.  If anything, C++ compilers
do *less* of it.  The reason is the compiler writers are spending so
much time getting the semantics right that they have no time to do much
optimization.

> There once was a time when there was a tight correlation between the C code
> and the assembly.

Turn off -O if you want that.

> I like Per's comments about not being able to produce a compiler that behaves
> like Linus would want.

Would you be willing to accept 50% slower code for tighter control?
(You could get the 50% back by personally directing every compiler
transformation, but you'd have to get them all right and then redo
them every time you change any of the code).

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

In message < 199902090116.RAA15478@atrus.synopsys.com > you write:
> 
> > I've yet to see *any reference* to the claim that it is *documented*
> > that the inline declaration *guarantees* that the function will always
> > be inlined.  Even with extern.  That was your assumption, reading
> > between the lines...
> 
> RTFM.
> 
> Remember, we are not talking about ISO C++ here.  We are talking about
> *C*, and specifically the GNU "extern inline" extension.  So the M to R
> is the gcc manual.
> 
> We may have an issue later on with C9X, which may define "extern inline"
> to mean something different.

I actually did, and while the discussion of "extern inline" strongly
implies that it is guaranteed behavior, it doesn't *really* come out
and say it.  There is a hedge above though in the sentence "Note that
certain usages in a function definition can make it unsuitable for
inline substitution."  It looks like that is just a hedge on automatic
inlining, but it is really a hedge on the whole process...

I do think that the language is ambiguous and definitely suggests
something that the compiler cannot guarantee.  That's why I've
submitted a patch to egcs-patches to clarify this:

	  http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00176.html

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Joe Buck]

> I've yet to see *any reference* to the claim that it is *documented*
> that the inline declaration *guarantees* that the function will always
> be inlined.  Even with extern.  That was your assumption, reading
> between the lines...

RTFM.

Remember, we are not talking about ISO C++ here.  We are talking about
*C*, and specifically the GNU "extern inline" extension.  So the M to R
is the gcc manual.

We may have an issue later on with C9X, which may define "extern inline"
to mean something different.

Re: kernel-2.2.1-undefined references.

[Joe Buck]

Linus writes, in response to a suggestion to use a special feature of
macros:

> Why don't you just remove "inline" completely, then?
> 
> It's apparently ok to break documented and existing behaviour of "inline". 
> Go read the gcc documentation about "extern inline", the whole thing is
> _designed_ to be a much more readable form of #define. 

Hmm.  Linus does seem to have a point here.  See the node "Inline"
in 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."

This seems to be a fairly strong promise that the function is guaranteed
to be either inline or to come out undefined (unless there is a second
non-extern-inline definition).

Many people have been answering based on general compiler principles
rather than by looking at the promises made in the gcc documentation for
an *extension*.

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

In message < 36BF8D9A.B14ABAE9@interaccess.com > you write:
> 
> It all depends on whether you are making an application compiler or a
> platform-independent assembler, which C originally was. If I wrote some
> code where I expect measurable time rolling and unrolling a stack frame
> going into a function, and it's not there because of an auto-inline
> optimization, I'd be screaming. 'volatile' functions are too weird at
> this late date.

C was never meant to be a "platform-independent assembler", the Bell
Labs guys already *had* BCPL.  Instead it was intended as a highly
efficient systems programming language.  You couldn't even say that it
was intended to be platform independent, since so much of the language
was explicitly left platform-dependent in order to promote
efficiency.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Bob McWhirter]

On Mon, 8 Feb 1999, Linus Torvalds wrote:

> On Mon, 8 Feb 1999, Lee Iverson wrote:
> > 
> > It occurs to me that we do, in fact have an acceptable method of
> > *guaranteeing* inlining of a *function* in gcc.  That is a combination
> > of a macro and the "Statement Expression" extension.
> 
> Sure. 
> 
> Why don't you just remove "inline" completely, then?

I'm probably coming into this waaaay too late, but I thought the
standards (C++ and C9X?) had definite things to say about what
'inline' should mean; that is, that it was a hint or recommendation
to the compiler, but by no means a direct imperative.

It seems that a guaranteed forced 'inline' would be non-conforming.

In that case, could there not be a magical Linus-Special Inline
such as __inline or otherwise, that'd be Just Like inline, but 
Better(tm)?

As far as egcs breaking things, I thought we pretty much expected
that (it's half the fun), and rely on gcc2 if we needed actual 
determinism. ;)

Feel free to ignore.

-Bob

--
Bob McWhirter    Shop Foreman, Decision Scientist, Cat Juggler 
Werken Digital   A division of the Benjamin J. Werken & Sons Company
bob@werken.com   http://www.werken.com./

Re: kernel-2.2.1-undefined references.

[Bryan W. Headley]

Ross Smith wrote:

> From: Per Bothner <bothner@cygnus.com>
> >
> >[Linus wrote:]
> >> I'm not trying to be unreasonable. I'm just saying that if there is a
> >> function that is marked inline that can be inlined, it _should_ be
> >> inlined, because the compiler _never_ knows better than the programmer.
> >
> >Er, the compiler often knows better than the programmer.  That is why
> >we use compilers - to free us from low-level and architecture-dependent
> >decisions.
> >
> >Note you have a rather atypical perspective.  You know the hardware
> >in depth, and you know which instruction sequences will be faster.
> >You probably know (or at least can make an informed guess) if inline
> >will help or hinder the code.  You also sometimes need precise control
> >over low-level code.
> >
> >We cannot design a compiler for the Linux Torvalds' of the world.
> >We have to do what is best for *most* programmers, while still
> >providing the needed tools for the experts.
>
> It occurs to me that the real problem here is that "inline" is being
> used to refer to two slightly different concepts, and some of the
> participants in this thread haven't noticed this and are talking past
> each other.
>
>   (A) inline == "I [the programmer] know exactly what this code is
>   supposed to do at low level, and I have determined that this function
>   must be inline for proper behaviour, so inline it or give me an error
>   if you [the compiler] can't."
>
>   (B) inline == "I [the programmer] believe this code would be more
>   efficient if this function were expanded inline, so please do so
>   unless you [the compiler] have a good reason to do otherwise."
>
> Linus wants (A), but the inline keyword, as defined by ISO C++,
> mandates (B). Exactly what consitutes a "good reason" is a function of
> compiler technology. In many cases, compilers *are* smarter (about
> certain specific things) than programmers, and will quite rightly
> override the programmer's choice. For inline, this is rare today, but
> will get more common until eventually "inline" goes the way of
> "register".
>

No, I heard more than that. Such as, the compiler may opt to make a function
into an inline based on optimization. Which scares the hell out of me, too.

The argument, though, should be telling you that basing a C compiler
front-end on top of a C++ engine is going to become more and more risky.
There once was a time when there was a tight correlation between the C code
and the assembly. With C++, with "hidden" destructors to deal with exception
handling, jump tables to give the feel of class heirarchy, etc., you cannot
say that anymore.

I like Per's comments about not being able to produce a compiler that behaves
like Linus would want. It sort of makes Messrs Kernighan, Richie and Thompson
just a little bit more special than they are already :-)

#include <bryan/has/little/respect/for/ansi/nor/iso/as/they/are/usually/10/years/behind>

--
____               .:.                 ____
Bryan W. Headley - bheadley@interaccess.com

Re: kernel-2.2.1-undefined references.

[H. Peter Anvin]

> 
> Of course inline is supposed to work, but as you've heard this is
> largely a question of *reliably* generating correct code and as in the
> past *your assumptions* about what the compiler should be doing rather
> than objectively documented behavior.  The compiler may not be living
> up to your expectations, and I know that it hasn't in the past, but
> just as in some of those cases (e.g. the asm clobbering issue or the
> inline+label addresses), the problem is that you are relying on
> behaviour that is either undocumented and thus not guaranteed or
> falling between the cracks of the implementation.
> 
> I think this is a case where the documentation is misleading.  It does
> suggest that inlining is not guaranteed, but IMO not as prominently as
> it should.  That is what you've been bit by, *not* a guarantee that
> isn't being honoured.
> 

On another note, however, it really sucks to have to rely on macro
expansion -- it wrought with pitfalls, and the syntax is different in
the most bleacherous manner (requiring \ at the end of each line.)  It
is much nicer to have the compiler check the syntax properly, but it
really requires it to work right.  Oh yes, __builtin_constant_p()
really, really ought to work properly in an inline...

	-hpa

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

In message < Pine.LNX.3.95.990208160839.433A-100000@penguin.transmeta.com > you w
rite:
> 
> 
> On Mon, 8 Feb 1999, Lee Iverson wrote:
> > 
> > It occurs to me that we do, in fact have an acceptable method of
> > *guaranteeing* inlining of a *function* in gcc.  That is a combination
> > of a macro and the "Statement Expression" extension.
> 
> Sure. 
> 
> Why don't you just remove "inline" completely, then?
> 
> It's apparently ok to break documented and existing behaviour of "inline". 
> Go read the gcc documentation about "extern inline", the whole thing is
> _designed_ to be a much more readable form of #define. 
> 
> Oh, well, I don't care any more. Make up your own rules, and break
> documented behaviour. 

I've yet to see *any reference* to the claim that it is *documented*
that the inline declaration *guarantees* that the function will always
be inlined.  Even with extern.  That was your assumption, reading
between the lines...

That said, the documentation *does* clearly seem to strongly imply
such a guarantee.  The hedging language that should be there *isn't*
except for the single line: "Note that certain usages in a function
definition can make it unsuitable for inline substitution."  Clearly
not as prominent as it should be.

Of course inline is supposed to work, but as you've heard this is
largely a question of *reliably* generating correct code and as in the
past *your assumptions* about what the compiler should be doing rather
than objectively documented behavior.  The compiler may not be living
up to your expectations, and I know that it hasn't in the past, but
just as in some of those cases (e.g. the asm clobbering issue or the
inline+label addresses), the problem is that you are relying on
behaviour that is either undocumented and thus not guaranteed or
falling between the cracks of the implementation.

I think this is a case where the documentation is misleading.  It does
suggest that inlining is not guaranteed, but IMO not as prominently as
it should.  That is what you've been bit by, *not* a guarantee that
isn't being honoured.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Bryan W. Headley]

Mike Stump wrote:

> > From: "H. Peter Anvin" <hpa@transmeta.com>
> > To: jbuck@Synopsys.COM (Joe Buck)
> > Date: Mon, 8 Feb 1999 11:09:32 -0800 (PST)
>
> > However, I think the right thing to do is to force an inline and if
> > it is impossible, document when it's impossible, and give an error.
>
> I don't agree.  We expect you to support your request in a compelling
> way.  I haven't seen anything compelling yet.  I think there is a real
> bug that needs to be fixed, on this we can agree, but when this bug is
> fixed, what is the difference between register and inline?  Look were
> register is today, totally ignored and totally meaningless.  inline is
> becoming much the same sort of thing, and we don't give hard errors if
> register fails, never have never will.  For consistency, inline should
> behave in a similar fashion.

Mike,

It all depends on whether you are making an application compiler or a
platform-independent assembler, which C originally was. If I wrote some
code where I expect measurable time rolling and unrolling a stack frame
going into a function, and it's not there because of an auto-inline
optimization, I'd be screaming. 'volatile' functions are too weird at
this late date.

This takes me back to the original arguments against C++, where you know
what you've written, but you're not sure how the compiler opted to
generate the code. A runtime environment where exception-handling guts
can't be easily guessed at. Of course if you've Stan Lippman's compiler
internals book, you'd know what cfront would do.

Having been moved into a java-like, you-guess-what-it's-doing
environment, I feel like writing a java assembler :-)

--
____               .:.                 ____
Bryan W. Headley - bheadley@interaccess.com

Re: kernel-2.2.1-undefined references.

[Linus Torvalds]

On Mon, 8 Feb 1999, Lee Iverson wrote:
> 
> It occurs to me that we do, in fact have an acceptable method of
> *guaranteeing* inlining of a *function* in gcc.  That is a combination
> of a macro and the "Statement Expression" extension.

Sure. 

Why don't you just remove "inline" completely, then?

It's apparently ok to break documented and existing behaviour of "inline". 
Go read the gcc documentation about "extern inline", the whole thing is
_designed_ to be a much more readable form of #define. 

Oh, well, I don't care any more. Make up your own rules, and break
documented behaviour. 

		Linus

Re: kernel-2.2.1-undefined references.

[Lee Iverson]

In message < 003c01be53b6$5b04ff40$a8a11dcb@animal.ihug.co.nz > you write:
> From: Per Bothner <bothner@cygnus.com>
> >
> >[Linus wrote:]
> >> I'm not trying to be unreasonable. I'm just saying that if there is a
> >> function that is marked inline that can be inlined, it _should_ be
> >> inlined, because the compiler _never_ knows better than the programmer.
> >
> >Er, the compiler often knows better than the programmer.  That is why
> >we use compilers - to free us from low-level and architecture-dependent
> >decisions.
> >
> >We cannot design a compiler for the Linux Torvalds' of the world.
> >We have to do what is best for *most* programmers, while still
> >providing the needed tools for the experts.
> 
> It occurs to me that the real problem here is that "inline" is being
> used to refer to two slightly different concepts, and some of the
> participants in this thread haven't noticed this and are talking past
> each other.
> 
>   (A) inline == "I [the programmer] know exactly what this code is
>   supposed to do at low level, and I have determined that this function
>   must be inline for proper behaviour, so inline it or give me an error
>   if you [the compiler] can't."

It occurs to me that we do, in fact have an acceptable method of
*guaranteeing* inlining of a *function* in gcc.  That is a combination
of a macro and the "Statement Expression" extension.

#define foo(_x) ({				\
  int x = (_x);					\
  /* Various commands */			\
  val;						\
)}

is *already* the exact equivalent of:

extern inline foo (int x) {
  /* Various commands */
  return val;
)  

except that it also says, "I know exactly what I'm doing and this function
*must* be inlined".  Surely the number of functions in the kernel
which *must* be inlined for correct functioning is small
transformation can be done and ensure that correct code is generated.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: kernel-2.2.1-undefined references.

[Ross Smith]

From: Per Bothner <bothner@cygnus.com>
>
>[Linus wrote:]
>> I'm not trying to be unreasonable. I'm just saying that if there is a
>> function that is marked inline that can be inlined, it _should_ be
>> inlined, because the compiler _never_ knows better than the programmer.
>
>Er, the compiler often knows better than the programmer.  That is why
>we use compilers - to free us from low-level and architecture-dependent
>decisions.
>
>Note you have a rather atypical perspective.  You know the hardware
>in depth, and you know which instruction sequences will be faster.
>You probably know (or at least can make an informed guess) if inline
>will help or hinder the code.  You also sometimes need precise control
>over low-level code.
>
>We cannot design a compiler for the Linux Torvalds' of the world.
>We have to do what is best for *most* programmers, while still
>providing the needed tools for the experts.

It occurs to me that the real problem here is that "inline" is being
used to refer to two slightly different concepts, and some of the
participants in this thread haven't noticed this and are talking past
each other.

  (A) inline == "I [the programmer] know exactly what this code is
  supposed to do at low level, and I have determined that this function
  must be inline for proper behaviour, so inline it or give me an error
  if you [the compiler] can't."

  (B) inline == "I [the programmer] believe this code would be more
  efficient if this function were expanded inline, so please do so
  unless you [the compiler] have a good reason to do otherwise."

Linus wants (A), but the inline keyword, as defined by ISO C++,
mandates (B). Exactly what consitutes a "good reason" is a function of
compiler technology. In many cases, compilers *are* smarter (about
certain specific things) than programmers, and will quite rightly
override the programmer's choice. For inline, this is rare today, but
will get more common until eventually "inline" goes the way of
"register".

But kernel programming (and a few other cases such as embedded systems)
is a special case, with unusual performance and low-level behaviour
requirements. A "gimme inline and keep your opinions to yourself" (i.e.
option A) keyword is really necessary. And the problem is that GCC has
traditionally (since before it included C++) used plain "inline" for
this, whereas ISO C++ (and, I believe, the upcoming C9X standard)
specifies option B.

As far as I can see, there are four possible resolutions:

  (1) Decide that EGCS will use the traditional GCC interpretation of
  "inline", i.e. option A. This would be unpleasant for non-kernel
  programmers, and while it wouldn't strictly violate the letter of
  the C++ standard, it would certainly violate the spirit.

  (2) Provide a compiler switch that indicates whether "inline" should
  have the traditional GCC meaning (option A) or the ISO C++/C9X
  meaning (option B).

  (3) Give "inline" the ISO C++/C9X meaning, and provide a new keyword
  (e.g. "__force_inline") that has option A semantics for the kernel,
  embedded system, etc. programmers. IMHO this is the best solution.

  (4) Use option A for C and option B for C++. Ugh.

(P.S. #insert <std_rant_about_americans_who_say_ansi_instead_of_iso>)

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
                               * * * * *
    To err is human. To really screw up requires the root password.

Re: kernel-2.2.1-undefined references.

[Mike Stump]

> From: "H. Peter Anvin" <hpa@transmeta.com>
> To: jbuck@Synopsys.COM (Joe Buck)
> Date: Mon, 8 Feb 1999 11:09:32 -0800 (PST)

> However, I think the right thing to do is to force an inline and if
> it is impossible, document when it's impossible, and give an error.

I don't agree.  We expect you to support your request in a compelling
way.  I haven't seen anything compelling yet.  I think there is a real
bug that needs to be fixed, on this we can agree, but when this bug is
fixed, what is the difference between register and inline?  Look were
register is today, totally ignored and totally meaningless.  inline is
becoming much the same sort of thing, and we don't give hard errors if
register fails, never have never will.  For consistency, inline should
behave in a similar fashion.