Re: kernel-2.2.1-undefined references.

[Lee Iverson <leei at ai dot sri dot com>]

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