Re: support of older compilers

From: Adam Heath (doogie_at_debian.org)
Date: 11/05/04

  • Next message: Henrik Nordstrom: "Re: [BK PATCH] Fix ip_conntrack_amanda data corruption bug that breaks amanda dumps"
    Date:	Fri, 5 Nov 2004 16:19:05 -0600 (CST)
    To: Willy Tarreau <willy@w.ods.org>
    
    

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Henrik Nordstrom: "Re: [BK PATCH] Fix ip_conntrack_amanda data corruption bug that breaks amanda dumps"

    Relevant Pages

    • Re: Which PIC18 C Compiler?
      ... Walter gave a good answer regarding recursion in 8051 compilers, totally unrelated to gcc and/or sdcc (since there is no gcc port for the 8051). ... But in my experience on ColdFire's and PPC's, it has generated similar to or better than the few commercial compilers I have seen. ...
      (comp.arch.embedded)
    • Re: math.nroot [was Re: A brief question.]
      ... >>> Ah, but as I've said before, virtually all C compilers on 754 boxes ... >>> happy to use gcc, they all could have used the older gcc spellings ... > use glibc, they all could have used the older glibc spellings. ... for setting traps) interfaces, and I can't be arsed to go through old ...
      (comp.lang.python)
    • Re: math.nroot [was Re: A brief question.]
      ... >> happy to use gcc, they all could have used the older gcc spellings ... parings of C compilers and C runtime libraries are ... use glibc, they all could have used the older glibc spellings. ... trap doesn't actually fire until the _next_ fp operation ...
      (comp.lang.python)
    • Re: var args in kernel?
      ... But the way how GCC (and probably other compilers) ... What would the struct look like? ... Mmh, I could, because GCC is wise enough to copy whole structs. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: What is Linux built with? (or, what does this question mean?)
      ... Isn't the kernel/distro nearly always built w/ gcc? ... Now some of us actually have other compilers as well and these could be ... specific to provide cache and other optimizing that can't be generic. ... gnu compile in a way that it gives some registers over to the kernel as far ...
      (alt.os.linux.suse)