Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!snorkelwacker!spdcc!ima!esegue!compilers-sender
From: worley@compass.com (Dale Worley)
Newsgroups: comp.compilers
Subject: Re: RS/6000 Optimizer breaks code -- suggestions?
Keywords: C, debug, optimize
Message-ID: <9008241836.AA07588@sn1987a.compass.com>
Date: 24 Aug 90 18:36:06 GMT
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: worley@compass.com (Dale Worley)
Organization: Compilers Central
Lines: 31
Approved: compilers@esegue.segue.boston.ma.us

[In reagard to two similar unions, only one of which has a tag, and which
don't do what the author expected.]
    Note that you define a tag "g" here.  Note that any other union or struct
    that "happens" to look like it does not have to *really* be implemented
    identically, *UNLESS* you reuse the tag!  (I assume you have defined
    "half" somewhere else).  If you have severely different expectations, you
    should take them up with the ANSI C Committee, as I believe this is in
    keeping with the standard.

    Here you define another union, but you did *NOT* use the tag "g".  As a
    result, the compiler has the freedom to "optimize" the layout of these
    distinct unions.

Strictly speaking, you're correct.  However, for any sane implementation,
there are some tight constraints: a pointer to a union must point to each
of its members (ANSI 3.5.2.1) -- therefore, all members start at the same
place, and so unions of the same types of fields pretty will have to be
laid out the same.

Again, if two structs are members of a union, and they have an initial set
of members of the same type, then those members have to be laid out the
same way (ANSI 3.3.2.3).

How this applies in this particular example, I don't know precisely, but
it's likely that the optimizer is disregarding one or the other of these
rules.

Dale Worley		Compass, Inc.			worley@compass.com
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.