Re: RS/6000 Optimizer breaks code -- suggestions?

[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
--

Return to the comp.compilers page.
Search the comp.compilers archives again.