I found this reference to similar xlc pointer aliasing options:
http://publib.boulder.ibm.com/infocenter/comphelp/v9v111/index.jsp?topic=/com.ibm.xlcpp9.aix.doc/compiler_ref/opt_alias.htm
backed out the "volatile" attributes from APR_RING_HEAD, tried -O2
-qalias=noansi which looks like the most conservative way to go for aliasing
with any optimization enabled, but I still see the loop. I'm surprised because
pointer aliasing sounds like the problem.
it would be nice if we could change the ring structure definitions so that it
is clear that the ring head contains the same type of thing that the ring
entries do, so compilers cannot get confused about what the ring entry pointers
might refer to. but I wouldn't want to have special cases for removal/addition
when the element is adjacent to the head, which Dean was so careful to avoid,
or code that has to use negative offsets to back up from the element link
fields to the begininning of the containing structure.
Greg
----- Original Message ----
From: Joe Orton <[EMAIL PROTECTED]>
[...]
Nice. There was discussion about a pointer aliasing issue in this code
before, though I can't find a reference. I think the issue you describe
matches that of a pointer aliasing bug, anyway; if xlc has an equivalent
of gcc's -fno-strict-aliasing that could be used to perhaps confirm it?
joe
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
