From owner-freebsd-questions@FreeBSD.ORG Sat Aug 2 09:19:24 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 2042A37B404 for ; Sat, 2 Aug 2003 09:19:24 -0700 (PDT) Received: from pop018.verizon.net (pop018pub.verizon.net [206.46.170.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0D3143F93 for ; Sat, 2 Aug 2003 09:19:22 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([151.205.189.55]) by pop018.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030802161922.BUFR11703.pop018.verizon.net@mac.com> for ; Sat, 2 Aug 2003 11:19:22 -0500 Message-ID: <3F2BE47A.5080302@mac.com> Date: Sat, 02 Aug 2003 12:19:06 -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@freebsd.org References: <3F1322A9.8080805@mac.com> <20030731225137.GA15353@rot13.obsecurity.org> <3F29C399.6070108@mac.com> <20030801020842.GA16234@rot13.obsecurity.org> <3F29D0E1.30800@mac.com> <20030801030039.GA87206@falcon.midgard.homeip.net> In-Reply-To: <20030801030039.GA87206@falcon.midgard.homeip.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from [151.205.189.55] at Sat, 2 Aug 2003 11:19:22 -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: Sat, 02 Aug 2003 16:19:24 -0000 Erik Trulsson wrote: > On Thu, Jul 31, 2003 at 10:30:57PM -0400, Chuck Swiger wrote: [ ... ] >> 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. > > Note that it is not necessarily gcc which is at fault for such > failures. It may be a bug in gcc, but it may also be a bug in the code > being compiled that has a bug that only shows up under higher > optimization levels. > The latter is probably somewhat more common actually. Does the last comment mean that you can provide at least one example of code which behaves differently when compiled with "cc -O" versus "cc -O2"? Otherwise, what does "more common" mean in the context of zero examples? [ ... ] >>...and makes it so that -O2, -O3, etc does not enable GCSE optimization. > > But if the bug is not in gcc but in the code being compiled (and which > only happens to show up when compiled with GCSE optimization) Even if the code contains a bug, "cc -O" and "cc -O -fgcse" should produce the same results. Excluding certain well-defined exceptions (-ffast-math comes to mind), compiler optimizations likes -fgcse are not allowed to change the meaning of compiled code, do we agree? > ...such a patch would disable this optimization for correct code also > even though it is not necessary there. Such a patch would disable the optimization for all cases. If there exists any lexically correct input source code (ie, which parses validly) where compiling with -fgcse results in different behavior, that optimization is unsafe and should not be enabled by -O2 in any circumstance. -- -Chuck