This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 4.4.1/linux 64bit: code crashes with -O3, works with -O2


2010/2/20 Richard Guenther <richard.guenther@gmail.com>:
> On Sat, Feb 20, 2010 at 1:38 PM, Christoph Rupp <chris@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

>
> 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.gcc@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.)
>>>
>>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]