http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
--- Comment #22 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-29 12:09:30 UTC --- > The pointers are constructed explicitly to never be dereferenced, only > compared for equality; if a dereference exists it would be a bug, but > I don't see one. APR_RING_SPLICE_HEAD does such a dereference as far I can see: #define APR_RING_SPLICE_HEAD(hp, ep1, epN, elem, link) \ APR_RING_SPLICE_AFTER(APR_RING_SENTINEL((hp), elem, link), \ (ep1), (epN), link) #define APR_RING_SPLICE_AFTER(lep, ep1, epN, link) do { \ APR_RING_PREV((ep1), link) = (lep); \ APR_RING_NEXT((epN), link) = APR_RING_NEXT((lep), link); \ APR_RING_PREV(APR_RING_NEXT((lep), link), link) = (epN); \ APR_RING_NEXT((lep), link) = (ep1); \ } while (0) #define APR_RING_NEXT(ep, link) (ep)->link.next #define APR_RING_PREV(ep, link) (ep)->link.prev > In the absence of such a smoking gun, can an C99 aliasing issue occur merely > in handling pointer equivalence? That would be a real compiler bug. :-) You seem to be quite familiar with the httpd code. Can you pinpoint what is miscompiled exactly in ap_core_input_filter or ap_core_output_filter? I'm not saying that the miscompilation comes from this strict aliasing issue, only that it might at this point.