> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
