Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: low level optimization
Message-ID: <1991Apr19.055002.3399@Think.COM>
Date: 19 Apr 91 05:50:02 GMT
References: <1991Apr17.225944.15261@zoo.toronto.edu> <1991Apr18.190403.29049@Think.COM> <21846@lanl.gov>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 28

In article <21846@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>The standard _allows_ the _USER_ to decide whether to compile separately
>or together.  In the standard, the word "may" applies to user choices,
>the corresponding constraint on implementations is that it _must_ work
>correctly when the user chooses to exercise the feature.  In this case,
>if the user chooses only to recompile one file and not any of the others
>(which is allowed by the "may" clause), the implementation _must_ allow
>this to be linked with the previously translated files to produce a
>program.

Once you invoke the implementation's extension that does inter-module
optimization (why does everyone keep calling this interprocedural analysis?
that usually refers to optimization across procedures within the same
file), you have ventured outside the scope of the standard, just as if you
had invoked a compiler option that enables some implementation-specific
feature.

Rather than referring specifically to files, the standard probably should
have described the behavior in terms of "translation units", which could
encompass multiple source files.  This would have allowed multifile
compilation to be defined in the standard, rather than making it an
extension, and then the semantics would be covered by the section you
quoted.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar