Re: support of older compilers
From: Adam Heath
Date: Fri Nov 05 2004 - 17:21:45 EST
On Fri, 5 Nov 2004, Willy Tarreau wrote:
> On Thu, Nov 04, 2004 at 05:39:08PM -0600, Adam Heath wrote:
> > Using an old version of gcc because it is faster at compiling is a
> > non-argument.
> If you can send to all of us for free some hardware which is twice as fast
> as what we have, which does not generate more heat and noise, then perhaps
> most of us will accept to use a twice as slow compiler. But not for long,
> since some may realize that they can produce quality code twice as fast on
> their new system ;-)
> At least, with fast machines and fast compilers, people have no excuse not
> testing the patches they send. A few years ago, broken & non-tested patches
> were very common. This could become standard again if everyone jumped into
> gcc 3.4 unconditionnaly.
My argument started when people starting complaining about new compilers being
slow, and using that as the only reason to not use them.
A single datapoint by itself can not be used in an argument here.
You are adding additional requirements(using older hardware), as that makes
the argument valid.
> > If they produce bad code, then that's a valid reason.
> > If they produce larger code, that is a valid reason.
> You can also ask the gcc people when they will decide to write a new version
> which is able to compile some code which compiles with the previous release.
> I have some tools which don't compile anymore with gcc 3 and error messages
> look more like insults than information, and I don't even know how to "fix"
> (adapt ?) them. This too is a valid reason to stick to older compilers.
Not always. Older gccs accepted bad code; you can't honestly expect newer
ones to always accept this bad code.
Note: I'm not saying that's the specific case here.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/