I have here a testcase where -fstrict-aliasing seems to miscompiles the code. $ gcc-4.4 tc.c -o tc && ./tc $ gcc-4.4 tc.c -o tc -O1 && ./tc $ gcc-4.4 tc.c -o tc -O1 -fstrict-aliasing && ./tc Segmentation fault $ gcc-4.4 tc.c -o tc -O1 -fstrict-aliasing -DOK && ./tc 0xaf8bea20 This also happens with the gcc-4.5 snapshot. > gcc-4.4 -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.4 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=i586-suse-linux Thread model: posix gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux) > gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-suse-linux/4.5/lto-wrapper Target: i586-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --enable-gold --with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic --build=i586-suse-linux Thread model: posix gcc version 4.5.0 20100331 (experimental) [trunk revision 157870] (SUSE Linux)
Created attachment 20302 [details] testcase Hopefully short enough to be a testcase. Left unprocessed to not prematurely clutter it.
You are accessing {lh,clh}.{next,prev} through a pointer to type struct item. Testcase can be fixed with givin clh and lh type struct item.
>You are accessing {lh,clh}.{next,prev} through a pointer to type struct item. Thank you for your time. I do have a few questions. I wonder where exactly I am doing that access. In the first part of the for clause, (pos) = list_entry((head)->next, typeof(*(pos)), member); head->next is valid, so only pos is punned. The second part is &(pos)->member != (void *)(head); This I can imagine blowing up; as pos will point to a non-existing memory block once the end of the list is reached. I thus replace that by the reverse of containerof to avoid dereferencing pos (/or accessing member/next through a pointer of the wrong type), IOW #define s_member(var, type, member) \ ((type *)((char *)var + offsetof(typeof(*var), member))) s_member(pos, struct list_head, member) != (void *)(head) On an empty list, the condition is not met, so the for loop stops and the third part of the for() is not evaluated. On a non-empty list, pos points to a valid memory region as long as it loops, so that the pos->member.next in 3rd part, (pos) = list_entry((pos)->member.next, typeof(*(pos)), member)) should be valid. Please correct me if I am wrong. Though I also have to employ s_member in the third case (pos) = list_entry(s_member((pos), struct list_head, member)->next, typeof(*(pos)), member)) to get rid of any visible artifacts (such as segfaults), but I suspect the underlying problem isn't eliminated.