buggy optimization levels...
Chuck Swiger
cswiger at mac.com
Thu Jul 31 19:31:07 PDT 2003
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.
--
-Chuck
More information about the freebsd-questions
mailing list