From owner-freebsd-questions@FreeBSD.ORG Thu Jul 31 19:31:07 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 259BE37B401 for ; Thu, 31 Jul 2003 19:31:07 -0700 (PDT) Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 510C143F93 for ; Thu, 31 Jul 2003 19:31:06 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([151.205.189.55]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030801023105.PJAE24927.pop016.verizon.net@mac.com> for ; Thu, 31 Jul 2003 21:31:05 -0500 Message-ID: <3F29D0E1.30800@mac.com> Date: Thu, 31 Jul 2003 22:30:57 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd Questions References: <3F1322A9.8080805@mac.com> <20030731225137.GA15353@rot13.obsecurity.org> <3F29C399.6070108@mac.com> <20030801020842.GA16234@rot13.obsecurity.org> In-Reply-To: <20030801020842.GA16234@rot13.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [151.205.189.55] at Thu, 31 Jul 2003 21:31:05 -0500 Subject: Re: buggy optimization levels... X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2003 02:31:07 -0000 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