Messages in this thread Patch in this message | | | Date | Sun, 23 Aug 1998 13:00:23 -0700 | From | "David S. Miller" <> | Subject | Re: pre egcs-1.1 testing and Linux 2.1.x |
| |
Date: Sun, 23 Aug 1998 21:34:46 +0200 (CEST) From: Andrea Arcangeli <arcangeli@mbox.queen.it>
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. */
This turns off certain optimizations entirely during the combine phase, plus you always reset it to being on, to a fixed value on top of that.
Combine does not check the variable 'optimize' anyways, most of the compiler works by checking specific flags. So the effect you are obtaining is that some other piece of code is checking optimize for a non-zero value and acting differently.
1) No comments explaining what the real intended effect of your change is.
2) No ChangeLog entry, explaining exactly what the results your patches are obtaining, and precisely what is being worked around and/or disabled in the compiler for correct operation.
--- /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)) { You're disabling an entire class of optimizations in the loop optimizer. Maybe this fixes a specific problem on ix86, but you don't mention what that is or why this makes a difference. Certainly this change should not happen on all other architectures too.
I think that gcc should be:
1. realiable 2. efficient and optimized
I think you are asking the egcs maintainers to look at this set of patches which disable a whole slew of optimizations and for them do all the work of finding out exactly what is the cause of things going wrong. The patch looks like it was a matter of "let's try disabling this and that, and see what works". This is useful for narrowing down the cause of the bug, but to use it as the direct result for the final patch, no way.
This patch should not go in as is, because it effects every platform gcc supports in unknown (an unnecessary) ways. But if you had documented what the intended ends were of your changes, maybe we could figure that out.
As it stands you've left the maintainer who looks at your patch with a lot of work to do.
Later, David S. Miller davem@dm.cobaltmicro.com
- 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
| |