From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/22
Message-ID: <Pine.LNX.3.96.980822110745.3907B-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 383763281
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.4.02A.9808212311020.10038-100000@brookie.inconnect.com>
Newsgroups: muc.lists.linux-kernel
I wanted to just clarify the issue of egcs and Linux-2.1.x.
I know that gcc has had problems with "regparm". However, I'm rather
disgusted with some egcs people who say "we have problems and they will
never get fixed". I don't personally believe in that kind of development
behaviour, and if it's true it is really sad.
I will continue to use "regparm" for the specific functions where I think
there's a noticeable win (either in performance or simplicity - when
mixing assembly and C the regparm calling convention can be much nicer to
use). And I hope that not all egcs people consider it impossible to fix
bugs, and that some of them will be instead more motivated to fix the
problems than to ignore them.
There certainly seems to be egcs versions that can't handle it at all, and
those versions won' tbe able to compile the kernel. It seems most egcs
versions are fine, and I'd continue to encourage people to try them out
because they obviously do generate better code for many people. I would
also encourage people that feel interested to help the egcs people to
create a better compiler and look into why egcs seems to have so many
problems with register allocation.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: da...@dm.cobaltmicro.com (David S. Miller)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/22
Message-ID: <199808222222.PAA09685@dm.cobaltmicro.com>#1/1
X-Deja-AN: 383789082
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980822110745.3907B-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
Date: Sat, 22 Aug 1998 11:18:47 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
I wanted to just clarify the issue of egcs and Linux-2.1.x.
I agree with your quibbles on the most part, _however_:
In this specific instance the regparm problems are a symptom of a much
larger issue, SMALL_REGISTER_CLASSES. Linus, I know when you want to
add regparm to some function you check it out to see if gcc
miscompiles it before actually using it for real right? Well the
reasons for these failure cases are actually known by the egcs
developers, and they realize how insurmountable it is to fix "right
this moment".
Richard Kenner made a huge mistake by letting regparm on the intel
into the gcc code in the first place, because of this crucial
fundamental flaw which prevents them from working reliably.
So don't blame the egcs people for trying to deal with the mess Kenner
created. Give them time, they will fix it eventually, believe me I am
working a lot on the egcs project so I know what kind of time frames
we are talking about here.
And if they can't fix egcs right now, or in the next release, in this
regard, cut them slack for once for crying out loud. They've chosen
to disable a feature instead of allowing it to generate incorrect
code. I think thats a good engineering decision.
Regparm was always broken, and you even know it, the egcs people are
acknowledging it's brokenness, and will (eventually) fix it. But for
now, until it is fixed and stops allowing miscompilation, it is off.
I think that with how much you knew yourself about it's brokenness,
relying on it for the few cases where your version of gcc happens to
get it right is playing with fire.
I'm just getting a little sick of the "I am Linus, hear me roar,
nobody use that f****d up EGCS compiler if it's developers don't
listen to everything I say and leave on all the features I want for
the kernel, even if they are broken." The people who sweat night and
day on egcs take offense to this, and now in this instance myself
included.
Later,
David S. Miller
da...@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <Pine.LNX.3.96.980823103007.8844B-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 383939744
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199808222222.PAA09685@dm.cobaltmicro.com>
Newsgroups: muc.lists.linux-kernel
On Sat, 22 Aug 1998, David S. Miller wrote:
>
> So don't blame the egcs people for trying to deal with the mess Kenner
> created. Give them time, they will fix it eventually, believe me I am
> working a lot on the egcs project so I know what kind of time frames
> we are talking about here.
I _am_ giving them time.
I'm not standing up on my soap-box and demanding that this be fixed. As I
mentioned, I've been rather careful about how I use regparm exactly
because I know gcc has some problems.
However, I will continue to ignore developers who don't say "we will fix
it eventually", but instead say "let's remove the feature, we'll never be
able to fix it". If I respected that kind of mentality I would be using
WNT. I don't.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: da...@dm.cobaltmicro.com (David S. Miller)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <199808231737.KAA16112@dm.cobaltmicro.com>#1/1
X-Deja-AN: 383939743
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980823103007.8844B-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
Date: Sun, 23 Aug 1998 10:33:23 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
However, I will continue to ignore developers who don't say "we
will fix it eventually", but instead say "let's remove the feature,
we'll never be able to fix it".
And the egcs team has not said the latter. But they will turn the
feature off until such time as the fix is made, since it generates
incorrect code.
Later,
David S. Miller
da...@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <Pine.LNX.3.96.980823114718.8844R-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 383957906
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199808231737.KAA16112@dm.cobaltmicro.com>
Newsgroups: muc.lists.linux-kernel
On Sun, 23 Aug 1998, David S. Miller wrote:
>
> However, I will continue to ignore developers who don't say "we
> will fix it eventually", but instead say "let's remove the feature,
> we'll never be able to fix it".
>
> And the egcs team has not said the latter. But they will turn the
> feature off until such time as the fix is made, since it generates
> incorrect code.
So how do you explain that one person already stepped up and said he has
had a patch for this problem for two years now?
And the patch wasn't a matter of disabling the feature.
How long do we have to go round the merry-go-round before the gcc people
start admitting to bugs instead of blaming the kernel when something goes
wrong?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: s...@cuci.nl (Stephen R. van den Berg)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <19980823204851.16065@cuci.nl>#1/1
X-Deja-AN: 383957907
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980823103007.8844B-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
David S. Miller wrote:
> From: Linus Torvalds <torva...@transmeta.com>
> However, I will continue to ignore developers who don't say "we
> will fix it eventually", but instead say "let's remove the feature,
> we'll never be able to fix it".
>And the egcs team has not said the latter. But they will turn the
>feature off until such time as the fix is made, since it generates
>incorrect code.
There always have been features which generated incorrect code in some
cases (heck, due to generic (but rare) bugs in gcc, all features eventually
generate incorrect code).
Disabling the feature completely creates a chicken and egg problem. If nobody
is able to use/test the feature, they'll not find out where it doesn't
work and it will likely not be fixed (there is little incentive to fix).
Chances are that (without having looked at egcs yet) simply not-allowing
indirect function calls to regparm functions fixes the problem completely.
I'll admit that actually fixing it correctly is a bit more involved and
probably not doable by your casual programmer who was just looking to see
his program running correctly, instead of planning on fixing gcc.
Given all the positive feedback, I'm thinking about getting
back in the game again and dig out my gcc patches to try and see
how much of it can be carried over to egcs.
--
Sincerely, s...@cuci.nl
Stephen R. van den Berg (AKA BuGless).
Skiing beyond this point may result in death and/or loss of skiing privileges.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <Pine.LNX.3.96.980823114054.8844N-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 383957908
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199808231737.KAA16112@dm.cobaltmicro.com>
Newsgroups: muc.lists.linux-kernel
On Sun, 23 Aug 1998, David S. Miller wrote:
>
> However, I will continue to ignore developers who don't say "we
> will fix it eventually", but instead say "let's remove the feature,
> we'll never be able to fix it".
>
> And the egcs team has not said the latter. But they will turn the
> feature off until such time as the fix is made, since it generates
> incorrect code.
People I trust tell me that the problem can occur even without regparm,
it's just that regparm is able to trigger the _real_ bug much more easily.
As such, disabling the feature pretty much amounts to hiding your head in
the sand.
Oh, well.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: da...@dm.cobaltmicro.com (David S. Miller)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <199808231854.LAA16670@dm.cobaltmicro.com>#1/1
X-Deja-AN: 383962545
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <19980823204851.16065@cuci.nl>
Newsgroups: muc.lists.linux-kernel
Date: Sun, 23 Aug 1998 20:48:51 +0200
From: "Stephen R. van den Berg" <s...@cuci.nl>
Given all the positive feedback, I'm thinking about getting back in
the game again and dig out my gcc patches to try and see how much
of it can be carried over to egcs.
Please do, you'll find that working with the egcs team compared to
working with Kenner is like night and day.
For example, I would have never written my Sparc backend rewrite and I
would not be working on a completely new register allocator right now
if Kenner was still in any way involved in gcc's main development.
Later,
David S. Miller
da...@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: a...@lxorguk.ukuu.org.uk (Alan Cox)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <m0zAgT1-000aPKC@the-village.bc.nu>#1/1
X-Deja-AN: 383967148
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980823114718.8844R-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
> How long do we have to go round the merry-go-round before the gcc people
> start admitting to bugs instead of blaming the kernel when something goes
> wrong?
Since when has been telling someone "we dont recommend you use that feature"
been blaming the kernel ?
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <Pine.LNX.3.96.980823124902.9050B-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 383976188
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <m0zAgT1-000aPKC@the-village.bc.nu>
Newsgroups: muc.lists.linux-kernel
On Sun, 23 Aug 1998, Alan Cox wrote:
>
> > How long do we have to go round the merry-go-round before the gcc people
> > start admitting to bugs instead of blaming the kernel when something goes
> > wrong?
>
> Since when has been telling someone "we dont recommend you use that feature"
> been blaming the kernel ?
NOBODY said "we don't recommend using the feature, because we know it has
problems but we hope to fix them"
Instead, people said "we're going to make the problem go away by hiding
the feature".
And THAT in turn means that we can't compile the kernel with such a
compiler.
To me, that sounds like blaming the feature that the kernel uses rather
than blaming the real bug.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <Pine.LNX.3.96.980823125344.9050C-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 383990689
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199808231854.LAA16670@dm.cobaltmicro.com>
Newsgroups: muc.lists.linux-kernel
On Sun, 23 Aug 1998, David S. Miller wrote:
>
> Please do, you'll find that working with the egcs team compared to
> working with Kenner is like night and day.
It's certainly different.
Kenners attention was hard to get. And sometimes when you got it he
replied with a "known problem, I don't [know how|have time] to fix it".
And sometimes he replied with a "here's a testing patch that may fix the
problem", and sometimes it did.
But I personally never had Kenner disable a feature because I could
reproduce a bug with it. When you told Kenner of a bug he acknowledged it
as a bug.
He may not have given it the attention it deserved, and I understand that
he was very hard to work with as a developer. I was happy that egcs came
to life because it was obvious that there were development problems due to
this.
But I'd be happier with a bit more of Kenneresque behaviour, and a bit
less of the "go away, we don't support this even though it's been there
for years" attitude.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: da...@dm.cobaltmicro.com (David S. Miller)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <199808232013.NAA17142@dm.cobaltmicro.com>#1/1
X-Deja-AN: 383985713
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980823125344.9050C-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
Date: Sun, 23 Aug 1998 13:06:52 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
But I personally never had Kenner disable a feature because I could
reproduce a bug with it. When you told Kenner of a bug he acknowledged it
as a bug.
BULL****, remember that whole "local label in inline function" fiasco?
That was a Kenner change in Kenner's tree, that I wanted to kill
before it got merged into the egcs tree. Case closed.
Don't make false claims. Kenner in this case did in fact disable a
feature instead of fixing the problem.
Later,
David S. Miller
da...@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <Pine.LNX.3.96.980823131708.9050E-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 383990691
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199808232013.NAA17142@dm.cobaltmicro.com>
Newsgroups: muc.lists.linux-kernel
On Sun, 23 Aug 1998, David S. Miller wrote:
>
> BULL****, remember that whole "local label in inline function" fiasco?
> That was a Kenner change in Kenner's tree, that I wanted to kill
> before it got merged into the egcs tree. Case closed.
That is sad.
That's the other real beef I've had with gcc development lately, and was
the reason I reacted so strongly to this. If that was Kenner, then I do
retract the statement that Kenner never did me no wrong. I just happened
to interact with the egcs people on it.
I've actually been very happy with gcc development 99% of the time. I
never had a problem at all until very recently, but now within a few
months of each other I've had two cases where I thought the maintainers
acted completely irrationally, wanting to disable features that had better
fixes.
[ Yes, even the "disable certain optimizations" patch is a better fix than
disabling the cases that can trigger the optimization bugs. No, I don't
like that patch either, but I like it a whole lot more than trying to
just make the bug harder to notice ]
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <Pine.LNX.3.96.980823133729.9050G-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 384000350
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199808232013.NAA17142@dm.cobaltmicro.com>
Newsgroups: muc.lists.linux-kernel
On Sun, 23 Aug 1998, David S. Miller wrote:
>
> BULL****, remember that whole "local label in inline function" fiasco?
> That was a Kenner change in Kenner's tree, that I wanted to kill
> before it got merged into the egcs tree. Case closed.
>
> Don't make false claims. Kenner in this case did in fact disable a
> feature instead of fixing the problem.
Btw, David, back then you had righteous indignation that he tried to do
that.
Why don't you feel the same righteous indignation this time?
Somebody tell me why it's ok to hide a problem now, when it wasn't before?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: da...@dm.cobaltmicro.com (David S. Miller)
Subject: Re: pre egcs-1.1 testing and Linux 2.1.x
Date: 1998/08/23
Message-ID: <199808232043.NAA17304@dm.cobaltmicro.com>#1/1
X-Deja-AN: 383995260
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980823133729.9050G-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
Date: Sun, 23 Aug 1998 13:39:50 -0700 (PDT)
From: Linus Torvalds <torva...@transmeta.com>
On Sun, 23 Aug 1998, David S. Miller wrote:
> Don't make false claims. Kenner in this case did in fact disable a
> feature instead of fixing the problem.
Btw, David, back then you had righteous indignation that he tried
to do that.
Because in that particular case Kenner disabled something in all
cases, when in fact he and the rest of us knew the problem he was
solving was only relevant in one case. And this is what Rth's version
of the fix took care of.
In this case nobody has a clear understanding of the set of cases
where the regparm feature will generate incorrect code. And we can't
make the same kinds of decisions until that set of cases becomes a
known instead of an unknown. (you don't even know, this is why you
check the compilers output when you try to use it in a new place)
Later,
David S. Miller
da...@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
|