On 24 Nov, 2013, at 03:37 , Mouse <mo...@rodents-montreal.org> wrote: >> [The compiler] also couldn't know if pointers whose types it did know >> were referring to different members of the same union, perhaps with >> the union declared in another compilation unit > > The text I have says > > [#5] One special guarantee is made in order to simplify the > use of unions: if a union contains several structures that > share a common initial sequence (see below), and if the > union object currently contains one of these structures, it > is permitted to inspect the common initial part of any of > them anywhere that a declaration of the completed type of > the union is visible. Two structures share a common initial > sequence if corresponding members have compatible types > (and, for bit-fields, the same widths) for a sequence of one > or more initial members. > > Note that the completed union declaration must be visible for this > exemption to apply, so as I read it the part after the last comma of > the quote I opened this mail with is wrong....
Ahh, I misremembered that. Since this misunderstanding was the basis for thinking it might be okay to access objects through different structure pointers as long as the member types matched what was stored, and since I know of no other part of the standard which would allow this, I can see why the compiler could choose to treat this as illegal when no union is visible. I guess that means the TAILQ macros really are an accident waiting to happen. That also makes it clear that, in the CIRCLEQ case, when the pointers compare equal then any use of both the pointers to access members would be out-of-spec aliasing. The comparison being deleted is in fact surrounded by code which uses the both pointers, so I can see why the compiler might be suspicious enough to warn about it, but the only actual aliased access is in a branch of the if()s the comparison would be correctly avoiding if the code were generated. It seems like the optimizer has moved from requiring that code not do anything which isn't explicitly allowed by the standard (the TAILQ case) to requiring code not do things which the standard explicitly allows but which may, in some circumstance, not be perfectly portable. I think getting rid of uses of the CIRCLEQ macros was the right thing to do in any case, since code which works like that doesn't need to exist. I'm not sure that that TAILQ macros are the best answer to the problem, though. Dennis Ferguson
