Re: kernel-2.2.1-undefined references.

[torvalds at transmeta dot com (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