http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
--- Comment #27 from Paulo César Pereira de Andrade <pcpa at mandriva dot com.br> 2010-11-29 21:26:32 UTC --- Created attachment 22572 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22572 test case I learned most of apache/apr/apr-util internals while debugging this problem in mandriva cooker, so, maybe the test case can be made simpler... The crash in mandriva is only confirmed to happen in i586. Sample run of the test case: [p...@localhost ~]$ gcc -O0 -fstrict-aliasing -D_LARGEFILE64_SOURCE -I/usr/include/apr-1 -g3 apr-test.c; LC_ALL=C ./a.out It works! [p...@localhost ~]$ gcc -O3 -fstrict-aliasing -D_LARGEFILE64_SOURCE -I/usr/include/apr-1 -g3 apr-test.c; LC_ALL=C ./a.out a.out: apr-test.c:59: check: Assertion `e->link.next->link.prev == e' failed. Abortado [p...@localhost ~]$ gcc -O3 -fno-strict-aliasing -D_LARGEFILE64_SOURCE -I/usr/include/apr-1 -g3 apr-test.c; LC_ALL=C ./a.out It works! [pardon choosing the "It works!" string :-)] It also appears to correct the issue with -fstrict-aliasing by adding temporaries, e.g: -#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_HEAD(hp, ep1, epN, elem, link) do { \ + struct elem *lep = APR_RING_SENTINEL((hp), elem, link); \ + APR_RING_SPLICE_AFTER(lep, (ep1), (epN), link); \ + } while (0) The attribute noinline in the test case was to "somehow" make gcc not understand where the pointers come from, otherwise, if removing any of them, it will also work.