Xref: utzoo comp.lang.c:38972 comp.std.c:4781
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!acorn!ixi!clive
From: clive@x.co.uk (Clive Feather)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: low level optimization
Message-ID: <May91.054032.5692@x.co.uk>
Date: 2 May 91 05:40:32 GMT
References: <1991Apr17.225944.15261@zoo.toronto.edu> <22839@lanl.gov> <5475@goanna.cs.rmit.oz.au>
Reply-To: clive@x.co.uk (Clive D.W. Feather)
Followup-To: comp.std.c
Organization: IXI Limited, Cambridge, UK
Lines: 74

In article <5475@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> The key difference is
> -- C permits aliasing.  The price of this is that in the absence of
>    good interfile analysis, you get inferior optimisation.  This is
>    a Quality of Implementation issue, because interfile analysis
>    _can_ be done without violating the standard.
> -- Fortran forbids aliasing.  The price of this is that in the
>    absence of good interfile analysis, the fact that the code that
>    has been generated is WRONG because there _is_ aliasing goes
>    quietly un-noticed.

[He's not the only one to do so, but this message was to hand when I
finally decided to contribute to this thread]

The standard (3.9.6) says:
   "The use of two parameters declared with an array type (prior to their
    adjustment to pointer type) in separate lvalues to designate the same
    object is an obsolescent feature."

Looking at this and the rationale, it seems to me that the intention of
the committee was:

    void mangle_two_arrays (double *a, double *b, size_t n)
    {
        /*
            The compiler must generate code which will work if a and b
            point to the same object, or if a == b + 1, etc. In other
            words, traditional C semantics.
            Future versions of the standard will retain these semantics.
        */
    }

    void mangle_two_arrays (double a [], double b [], size_t n)
    {
        /*
            At present this has the same semantics as above. However,
            a future version of the standard will probably change the
            semantics of this procedure to those in the following comment;
            compiler implementers should look at this as a reasonable
            extension, and programmers should use this notation when they
            want these semantics.
        */
        /*
            The compiler is entitled to assume that a and b point to
            different objects, and having them point to the same object
            will cause undefined behaviour. In other words, Fortran
            semantics.
        */
        /*
            If this procedure only accesses a [0] to a [n-1] and b [0]
            to b [n-1], it is presumably safe for b == a + n. However,
            it is undefined what happens if b == a + n - 1, even if
            the code is such as the following.
        */

        size_t i;

        for (i = 0; i < n; i++)
            b [i] = sin (a [i]) - cos (b [i]);
    }

What I am wondering is:

(1) am I reading the standard correctly ?
(2) why hasn't Chris Torek (or Doug Gwyn or Henry Spencer or Mark Brader
or ...) mentioned this before ?
(3) is Chris wrong (shock, horror; I can sense the flames coming at me
already :-) when he says that declaring a parameter as an array is
always a Bad Thing (TM) ?
-- 
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
clive@x.co.uk          | 62-74 Burleigh St.  | it will get its revenge.
Phone: +44 223 462 131 | Cambridge   CB1 1OJ |   - Henry Spencer
(USA: 1 800 XDESK 57)  | United Kingdom      |