From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!ucbvax!grebyn.COM!karl From: karl@grebyn.COM (Karl A. Nyberg) Newsgroups: comp.lang.ada Subject: optimizations Message-ID: <8802101831.AA19990@grebyn.com> Date: 10 Feb 88 18:31:55 GMT References: <8802101756.AA06942@ajpo.sei.cmu.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: I presume you had intended this for info-ada, and not info-ada-request? If so, please mail it again. Thanks. -- Karl -- Received: by grebyn.com (1.2/smail2.3/07-01-87) id AA19926; Wed, 10 Feb 88 13:17:47 est Received: by grebyn.com (1.2/smail2.3/07-01-87) id AA19917; Wed, 10 Feb 88 13:17:40 est Received: from AJPO.SEI.CMU.EDU by umd5.UMD.EDU (5.54/umd.04) for grebyn.COM!karl id AA25998; Wed, 10 Feb 88 13:07:06 EST Message-Id: <8802101756.AA06942@ajpo.sei.cmu.edu> Received: from TL-20B.ARPA by SIMTEL20.ARPA with TCP; Wed, 10 Feb 88 10:56:30 MST Received: ID ; Wed 10 Feb 88 12:55:27-EST Date: Wed 10 Feb 88 12:55:24-EST From: umd5!TL-20B.ARPA!PLOEDEREDER Subject: optimizations To: info-ada-request@simtel20.arpa Cc: ploedEREDER@tl-20b.arpa I have followed the discussion on optimization with considerable interest and was truly astonished about the (mis)conceptions that seem to exist. There is a first law of code optimization (and code generation in general) that must never be violated: THE OBSERVABLE SEMANTICS OF EXECUTING CODE MUST NOT BE IN VIOLATION OF THE LANGUAGE DEFINITION. "Observable" in the statement above means a difference in input/output or execution behavior of the program (it does not mean "observable in the assembly code"). Optimization is not a carte blanche for the compiler implementer to "optimize" into code that is 99% correct and fails to conform to the language definition in 1% of all possible cases. The example in case is definitely a bug in the compiler. The semantics of assignment are copy semantics by language definition. Thus X: STRING := Y.all; must have the observable semantics of copying the string contents of Y (and not just copying the pointer value of Y). A compiler may optimize this assignment into a pointer assignment ONLY IF the observable semantics are as if the string were copied. This is not the case in the example, since, after deallocation, it is indeed observable that the semantics of the program have been altered in violation of the prescribed language definition of assignment. The situation would be entirely different if the Ada source had copied the pointer value, i.e., "X := Y"; in this case, subsequent deallocation applied to Y does indeed make any reference to the contents of X erroneous by language definition. As a final note to comments that recommend supressing optimization to ensure "proper" observation of semantics: You will note that the "law" that I cited above applies to non-optimizing code generation as well. If your Ada code relies on semantics not prescribed by the language definition, its portability (to another system or to another compiler on the same system, or even to the next release of the same compiler) will be severely endangered, since compilers WILL differ in their choice of implementation-defined semantics. I refer you to publications by John Nissen et al. or by the ARTEWG that delineate many of the areas of implementation-defined semantics, so you can write code that does not rely on unjustified assumptions about the prescribed semantics of Ada. Erhard Ploedereder Tartan Laboratories PLOEDEREDER@TL-20B.ARPA -------