On Mon, 2010-02-22 at 21:17 +0100, Christoph Rupp wrote: > 2010/2/20 Richard Guenther <richard.guent...@gmail.com>: > > On Sat, Feb 20, 2010 at 1:38 PM, Christoph Rupp <ch...@crupp.de> wrote: > [...] > >> I fixed all warnings regarding dereferencing type-punned pointers and > >> I compile with -O3 AND -fno-strict-aliasing. > >> > >> and i still get the same crash as earlier. it does not crash with -O2. > >> > >> From what i understand the -fno-strict-aliasing should solve the > >> problem, but it doesn't. > >> > >> The function which crashes basically is searching a bitmap for a > >> pattern. When the search starts, it uses two pointers to the same > >> memory location (u64 ptr for searching in 8byte-steps, char* ptr for > >> searching byte-wise). If i understand the aliasing correctly then this > >> might cause the problems. I just don't know how to rewrite the > >> function - I want to use those two pointers for performance reasons. I > >> don't even know if the problem is in this function or if it's > >> somewhere else and the crash is just a side-effect of a completely > >> different problem. > > > > With -fno-strict-aliasing this is perfectly valid so the problem must be > > elsewhere. It might be alignment related if you do not make sure > > that the u64 accesses are properly aligned. Try -O3 -fno-tree-vectorize > > or analyze the crash. > > If i enable -fno-tree-vectorize for one file (that's the file which > produces the crash) everything works. > > For me this workaround is fine, although this file is performance > relevant and i'd like to have every optimization that's available. > > I don't really understand how alignment issues could cause this crash. > i'm only building for x86_64 and i was not aware of any alignment > requirements (i'd love to test on a SPARC, but sadly i don't have > access to one...) > > BTW - if i execute this in valgrind then it doesn't crash or give warnings. > > For me this looks cheesy - there are no gcc warnings, -O2 works, -O3 > crashes. MSVC works and older gcc versions also work fine. In this > case it's hard for me not to blame gcc for the crash. > > Anyway - thanks for your help! > Christoph
Vector instructions usually require aligned data. Perhaps the vectorizer assumes that a pointer to 64-bit data will only be used to access data that is 64-bit aligned. If you can reproduce the problem with a small, self-contained test then please file a bug report. It might be possible to issue a warning or to detect that the loop should not be vectorized. If not, maybe the compiler should disable vectorization for -fno-strict-aliasing. Janis > > > > Richard. > > > >> To reproduce: > >> wget http://crupp.de/hamsterdb-1.1.3.tar.gz > >> tar -zxvf hamsterdb-1.1.3.tar.gz > >> cd hamsterdb-1.1.3 > >> ./configure > >> make > >> cd unittests > >> ./test # <-- will segfault with a bad pointer > >> > >> Here's my gcc version: > >> Using built-in specs. > >> Target: x86_64-linux-gnu > >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu > >> 4.4.1-4ubuntu9' > >> --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs > >> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > >> --enable-shared --enable-multiarch --enable-linker-build-id > >> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > >> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 > >> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu > >> --enable-libstdcxx-debug --enable-objc-gc --disable-werror > >> --with-arch-32=i486 --with-tune=generic --enable-checking=release > >> --build=x86_64-linux-gnu --host=x86_64-linux-gnu > >> --target=x86_64-linux-gnu > >> Thread model: posix > >> gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) > >> > >> Thanks for any help, > >> Christoph > >> > >> > >> 2010/1/14 Jonathan Wakely <jwakely....@gmail.com>: > >>> 2010/1/14 Christoph Rupp: > >>>> > >>>> To reproduce, these steps are necessary: > >>>> > >>>> wget http://crupp.de/dl/hamsterdb-1.1.1.tar.gz > >>>> tar -zxvf hamsterdb-1.1.1.tar.gz > >>>> cd hamsterdb-1.1.1 > >>>> ./configure --enable-internal > >>>> make > >>> > >>> There are lots of these warnings, which you ignore at your peril: > >>> > >>> freelist.c:3326: warning: dereferencing type-punned pointer will break > >>> strict-aliasing rules > >>> > >>> ham_info.c:80: warning: dereferencing type-punned pointer will break > >>> strict-aliasing rules > >>> > >>> env.cpp:1804: warning: dereferencing type-punned pointer will break > >>> strict-aliasing rules > >>> > >>> You should probably either fix those warnings, avoid compiling at high > >>> optimisation levels, or use -fno-strict-aliasing (which allows the > >>> tests to run successfully.) > >>> > >> > >
