lkml.org 
[lkml]   [1998]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.125 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site