|RS/6000 Optimizer breaks code -- suggestions? firstname.lastname@example.org (1990-08-18)|
|RS/6000 Optimizer breaks code -- suggestions? email@example.com (1990-08-21)|
|Re: RS/6000 Optimizer breaks code -- suggestions? firstname.lastname@example.org (1990-08-24)|
|Re: RS/6000 Optimizer breaks code -- suggestions? email@example.com (1990-08-25)|
|Re: RS/6000 Optimizer breaks code -- suggestions? firstname.lastname@example.org (1990-08-27)|
|Re: RS/6000 Optimizer breaks code -- suggestions? email@example.com (1990-08-27)|
|Re: RS/6000 Optimizer breaks code -- suggestions? firstname.lastname@example.org (1990-08-29)|
|From:||email@example.com (Dave Gillespie)|
|In-Reply-To:||firstname.lastname@example.org's message of 24 Aug 90 18:36:06 GMT|
|Keywords:||C, optimize, debug|
|Organization:||California Institute of Technology|
|Date:||25 Aug 90 21:09:17|
>>>>> On 24 Aug 90 18:36:06 GMT, email@example.com (Dale Worley) said:
>> 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 188.8.131.52) -- 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 184.108.40.206).
> ... it's likely that the optimizer is disregarding one or the other of these
I don't have the original code handy, but as I recall it did not take
the addresses of both the unions in question, nor did the unions contain
at least two different structs. So the optimizer is probably right to
disregard these rules---they don't apply in this particular example.
In fact, if the C standard mentions the things you refer to above, but
also explicitly makes no guarantees about general relationships among the
fields of a union, then probably allowing this optimization was exactly
what the standard-writers had in mind.
But, having said all that, I actually agree with your assertion that the
implentation is not "sane", but only because the situations where it's
safe to rearrange a union are probably rare, and more often than not will
occur because the programmer was trying to use the union to fake up a
type cast. So the optimization is more likely to hurt than to help.
256-80 Caltech Pasadena CA USA 91125
[Can someone run the original code through the RS/6000 compiler, look at
the object code, and report whether the compiler is in fact doing something
strange? IBM is usually pretty good at reading standards. -John]
Return to the
Search the comp.compilers archives again.