>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
regparm(0).
>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
code.
Andrea[s] Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html