Re: in which we present an ugly hack to make sys/queue.h CIRCLEQ work

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> It isn't perfectly clear to me that this code has an aliasing problem
> the way it is, though.

gcc thinks it does, apparently.

> The only thing that matters in the standard are the types of the
> lvalue expressions used to access object in storage.  The lvalue
> expression types used to access the objects in storage in this case
> are 'type **', 'type **' and 'type *',

Um, some of them.  There are also the containing objects, which have
(incompatible) struct types (in CIRCLEQ_INSERT_HEAD, for example, I see
both "(elm)->field" and "(head)").  Because the struct types are
incompatible, the compiler is allowed to assume they do not alias one
another, which leads to optimizing away comparisons and thereby
producing nonworking code.

That these lvalue expressions are then further dissected via struct
member access doesn't really change this.

> I would be interested in knowing an actual example of the comparison
> problem with the CIRCLEQ macro, if the concern isn't theoretical.

Well, mrg wrote, when starting the thread,

< while preparing to update to GCC 4.8 i discovered that our
< sys/queue.h CIRCLEQ macros violate C aliasing rules, ultimately
< leading to the compiler eliding comparisons it declared as always
< false.

which sure looks to me as though it's not just theoretical.  (I don't
know personally; mrg's mail implies this was with gcc 4.8, which I
don't run.)

> Since the C standard explicitly allows a pointer to a structure type
> to be converted to the type of its first member and back, to another
> structure type and back, or to char * or void * and back, the fact
> that the two pointers point at different structure types is by itself
> insufficient to prove that they would not compare equal when suitably
> converted.

True but irrelevant.  Whether they actually would compare equal is
irrelevant; since the code follows those pointers, if they do point to
the same object then the code violates the quoted constraint and thus
is off in pure nasal demon territory.  So the compiler is entirely
within its rights to assume they do not point to the same object and
thus optimize away the comparison.

> It seems like that conclusion would minimally need to depend on
> proving that there was no possible use of the structure pointers
> which wouldn't violate the aliasing requirements, i.e. that that are
> no structure members at the same offsets which have compatible types.

Again, you're ignoring the struct-valued lvalue expressions involved,
focusing instead on the member-reference expressions containing them.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B