Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!apple!snorkelwacker!mintaka!spdcc!ima!esegue!compilers-sender From: daveg@near.cs.caltech.edu (Dave Gillespie) Newsgroups: comp.compilers Subject: Re: RS/6000 Optimizer breaks code -- suggestions? Keywords: C, optimize, debug Message-ID: Date: 25 Aug 90 20:09:17 GMT References: <9008241836.AA07588@sn1987a.compass.com> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: daveg@near.cs.caltech.edu (Dave Gillespie) Organization: California Institute of Technology Lines: 45 Approved: compilers@esegue.segue.boston.ma.us In-Reply-To: worley@compass.com's message of 24 Aug 90 18:36:06 GMT >>>>> On 24 Aug 90 18:36:06 GMT, worley@compass.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 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). > ... it's likely that the optimizer is disregarding one or the other of these > rules. 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. -- Dave -- Dave Gillespie 256-80 Caltech Pasadena CA USA 91125 daveg@csvax.cs.caltech.edu, ...!cit-vax!daveg [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] -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.