Kris Kennaway wrote:
On Thu, Jul 31, 2003 at 09:34:17PM -0400, Chuck Swiger wrote:
OK. Can the existence of such problems be confirmed reliably, say by regression testing?

The problem is in identifying precisely which piece of code is failing. A regression test is only useful if it concisely exercises a specific set of tests. As I said, in theory any optimization problems can be tracked down to the failure of a certain piece of code, but in something as large as the kernel it is not usually easy.

Ah, my apologies-- I believe I see where the confusion lies.

I understand that figuring out why the kernel died can be hard, particularly if the failures aren't concise and completely reproducable, and thus tracing the problem back to making the right change to gcc to fix the optimization that caused the observed failure is thus also hard.

Fine. However, you don't _need_ to identify the reason why the kernel died, or solve the bug in global common expression elimination to solve the problem of compiling the system with "cc -O2" resulting in a buggy kernel. If you determine that compiling with "cc -O -fgcse" results in failures, one does:

--- toplev.c_old        Thu Jul 31 22:23:22 2003
+++ toplev.c    Thu Jul 31 22:24:01 2003
@@ -4916,7 +4916,6 @@
       flag_cse_follow_jumps = 1;
       flag_cse_skip_blocks = 1;
-      flag_gcse = 1;
       flag_expensive_optimizations = 1;
       flag_strength_reduce = 1;
       flag_rerun_cse_after_loop = 1;

...and makes it so that -O2, -O3, etc does not enable GCSE optimization.


_______________________________________________ [EMAIL PROTECTED] mailing list To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to