The proposed ANSI C++ standard (April 1995 working paper, section 5.0,
paragraph 13) has this to say about aliasing:

If the program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined:

   1.the dynamic type of the object,
   2.a cv-qualified version of the declared type of the object,
   3.a type that is the signed or unsigned type corresponding to the
     declared type of the object,
   4.a type that is the signed or unsigned type corresponding to a
     cv-qualified version of the declared type of the object,
   5.an aggregate or union type that includes one of the aforementioned
     types among its members (including, recursively, a member of a
     subaggregate or contained union),
   6.a type that is a (possibly cv-qualified) base class type of the
     declared type of the object,
   7.a char or unsigned char type.
--

- Bill Seurer     ID Tools and Compiler Development      IBM Rochester, MN
  BillSeurer@vnet.ibm.com                               BillSeurer@aol.com
  Home page:  http://members.aol.com/BillSeurer
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

err@raelity.com (Ernie Rael) writes:

|>  According to to a compiler vendor i'm dealing with (this
|>  arises from a problem with the optimizer)
|>
|>      C++ aliasing rules say that storing through "pointer to
|>      type A" does NOT affect memory pointed to by pointers of
|>      type "pointer to type B" (except for "pointer to char").
|>
|>  I can't find anything in the draft standard that implies
|>  this or otherwise addresses the issue. I'm sure i'm
|>  misinterpreting something, or i just haven't seen the
|>  relevent text. Can someone point me to the section to
|>  check out.

>From memory, and from the C standard, this is implicit in the fact that
casting from type A* to B* is (in general) undefined, and casting from
void* is only defined if the void* was initialized by a pointer of the
same type.  This means that in fact, except for special cases, there is
no legal way to create a B* which in fact points to an A*.

This is, as I say, from memory, and from the C standard.  As has
recently been pointed out to me in another thread, the C++ standard
defines casting A*->B* to "work" if B* has less strict or equal
alignment requirements, so the compiler vendor's assertion would be
false in a significant number of cases.  (It is obviously false if the A
is type void, type unsigned char, or a base class of B.)

|>  I seem to remember something like this, but not where i saw
|>  it. It wasn't a draft c++ standard, since i've only started
|>  perusing it since this issue came up (dec96pub).
|>
|>  After considerable macro expansion, the simple program
|>  in question looks like:
|>
|>  1. p = 0;
|>  2. *((int *)&p) = x;
|>  3. L.item = p;
|>  4. printf(...,L.item);
|>
|>  The NO aliasing rule implies that the store at 2. cannot modify
|>  the value of p, because p is of type GenPtr, and the object
|>  being stored into is of type int.  Therefore the compiler looks
|>  around and notices that the last value assigned to p was the 0 from
|>  stmt 1., and L.item ends up with the wrong value.

As I remember the rules (and remember, this is my sometimes faulty
memory, not confirmed), line 2 results in undefined behavior according
to the C standard.  If this is true, the compiler is need not take it
into account when optimizing.

|>  I've fixed the code to avoid the problem, but would like
|>  to study the draft standard on this issue, and see if there
|>  is something open to interpretation.

In real life, of course, regardless of what the standard says, good
optimizers need to restrict aliasing, and will.  If the standard allows
this sort of code, the vendor will simply document the fact that such
and such level of optimizing will cause problems should not be used if
aliasing is used, and still make it available to the vast majority of
programs without this type of aliasing.  Also, even if the standard bans
this, a good vendor will have an option which will make it work, albeit
with a lower level of optimizing.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

According to to a compiler vendor i'm dealing with (this
arises from a problem with the optimizer)

    C++ aliasing rules say that storing through "pointer to
    type A" does NOT affect memory pointed to by pointers of
    type "pointer to type B" (except for "pointer to char").

I can't find anything in the draft standard that implies
this or otherwise addresses the issue. I'm sure i'm
misinterpreting something, or i just haven't seen the
relevent text. Can someone point me to the section to
check out.

I seem to remember something like this, but not where i saw
it. It wasn't a draft c++ standard, since i've only started
perusing it since this issue came up (dec96pub).

After considerable macro expansion, the simple program
in question looks like:

1. p = 0;
2. *((int *)&p) = x;
3. L.item = p;
4. printf(...,L.item);

The NO aliasing rule implies that the store at 2. cannot modify
the value of p, because p is of type GenPtr, and the object
being stored into is of type int.  Therefore the compiler looks
around and notices that the last value assigned to p was the 0 from
stmt 1., and L.item ends up with the wrong value.

I've fixed the code to avoid the problem, but would like
to study the draft standard on this issue, and see if there
is something open to interpretation.

-ernie
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]