[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3

["ebotcazou at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488

--- Comment #20 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-29 11:15:58 UTC ---
> We changed the macro from that to the current definition to avoid strict
> aliasing warnings from gcc:
> 
>   http://svn.apache.org/viewvc?view=revision&revision=662299

Bummer. :-)

> Does the cast through a char * not have the desired effect of allowing the
> pointer to alias any other pointer regardless of type?  That is one of the
> exceptions in C99 6.5/par 7.

Classical misconception.  What matters is the type of the lvalue used to access
the object, not the types through which the pointer value is casted, i.e:

  float f = 0.0;
  int t;

  t = *(int *)(char *)&f;

is as erroneous as:

  float f = 0.0;
  int t;

  t = *(int *)&f;

> Why specifically does this result in an C99 aliasing violation anyway?  The
> pointers to which this macro evaluates are never dereferenced, only compared
> for equality.

I think they are dereferenced by the macro APR_RING_{NEXT,PREV} in some cases.