From owner-freebsd-questions@FreeBSD.ORG Sat Aug 2 12:52:44 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 F1D9537B401 for ; Sat, 2 Aug 2003 12:52:43 -0700 (PDT) Received: from pop018.verizon.net (pop018pub.verizon.net [206.46.170.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id F300F43FBF for ; Sat, 2 Aug 2003 12:52:42 -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 <20030802195242.DCNH11703.pop018.verizon.net@mac.com> for ; Sat, 2 Aug 2003 14:52:42 -0500 Message-ID: <3F2C1679.5010702@mac.com> Date: Sat, 02 Aug 2003 15:52:25 -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> <3F2BE47A.5080302@mac.com> <20030802174536.GA14507@falcon.midgard.homeip.net> In-Reply-To: <20030802174536.GA14507@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 14:52:41 -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 19:52:44 -0000 Erik Trulsson wrote: [ ... ] > A somewhat contrived example that behaves differently when compiled > with -O3 or when compiled with -O2 or lower optimization follows: > > static int f(int a) > { > return a/0; > } > int main(void) > { > int x; > x = f(5); > return 0; > } Contrived, but interesting and useful nonetheless; thanks for the response. [ ... ] >> 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? > > Not quite. Compiler optimization flags (with a few exceptions like > -ffast-math) are not allowed to change the semantics of the compiled > code. I really don't want to debate the use of "meaning" versus "semantics". :-) > For buggy code that invokes undefined behaviour (divison by > zero, accessing unallocated memory, etc.) there is no semantics to > preserve and therefore the compiled code may well produce different > results when compiled with different flags. C code that permits a divide-by-zero condition will result in a runtime error, but I disagree that this has "no semantics to preserve". If the code was using floating point, IEEE 754 defines semantics for divide-by-zero one could also have an 'Infinity' result, but that's not available with ints; your code results in a SIGFPE being generated. > (Undefined behaviour in the context of the C standard means the > compiler is allowed to do whatever it damn well pleases, including, but > not limited to, doing what you wanted and expected it to do, formatting > your harddisk or making demons fly out of your nose. Sure. I see and acknowledge the validity of your point: it's possible for a programmer to write code which has different behavior depending on (say) -finline-functions. However, that being said, the fact that the C standard says such-and-such gives "undefined behavior" does not preclude the implementation from defining the behavior for such-and-such. >> 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. > > With that definition just about *all* optimizations would be unsafe. > > (And optimization is actually *supposed* to give different behaviour. > The running time of a program is part of its behaviour and > optimization is generally supposed to reduce the running time, thereby > giving different behaviour.) What you say is so obviously correct that one should instead conclude that my use of the term 'behavior' with regard to compiler optimizations has a more specific meaning. Page 586 of _Compilers: Principles, Techniques, and Tools_ states: First, a transformation must preserve the meaning of programs. That is, an "optimization" must not change the output produced by a program for a given input, or cause an error, such as a division by zero, that was not present in the original program. The influence of this criterion prevades this chapter; at all times we take the "safe" approach of missing an opportunity to apply a transformation rather than risk changing what the program does. -- Like your divide-by-zero example above, or this paragraph about "semantics" vs "meaning", I'm not going to disagree if you want to state that the running time of a program is part of the "behavior". However, using the terms in such a fashion precludes you from understanding the intended meaning in this particular context. -- -Chuck