[lkml]   [1998]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: pre egcs-1.1 testing and Linux 2.1.x
    On Sat, 22 Aug 1998, David S. Miller wrote:

    >developers, and they realize how insurmountable it is to fix "right
    >this moment".

    This my patch is the needed fix (the kernel reach execve("/sbin/init")):

    --- /tmp/gcc-2.8.1/toplev.c Thu Feb 26 03:04:46 1998
    +++ gcc-2.8.1/toplev.c Thu Jul 9 17:13:10 1998
    @@ -3393,8 +3393,10 @@

    /* If -opt, try combining insns through substitution. */

    + optimize = 0;
    if (optimize > 0)
    TIMEVAR (combine_time, combine_instructions (insns, max_reg_num ()));
    + optimize = 1;

    /* Dump rtl code after insn combination. */

    --- /tmp/gcc-2.8.1/loop.c Fri Feb 6 20:23:34 1998
    +++ gcc-2.8.1/loop.c Thu Jul 9 17:08:55 1998
    @@ -3037,6 +3037,7 @@
    register int count = 0;
    register rtx dest;

    + return;
    bzero ((char *) last_set, nregs * sizeof (rtx));
    for (insn = from; insn != to; insn = NEXT_INSN (insn))
    optimize can be restored also to 2 I think btw. It' s an optimization bug.
    I think that gcc should be:

    1. realiable
    2. efficient and optimized

    >Richard Kenner made a huge mistake by letting regparm on the intel

    The mistake is been done by the guy that projected the i386 calling
    convention and that forced us to use the stack for every call. If the
    calling convention would ever been regparm(3) gcc now would be buggy with

    >into the gcc code in the first place, because of this crucial
    >fundamental flaw which prevents them from working reliably.

    If there is some code that can' t be compiled using regparm(3) gcc should
    at least die and not generate buggy code silenty.

    >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.

    No. They should turn off optimization to be sure to not generate buggy

    Andrea[s] Arcangeli

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.021 / U:3.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site