Date: Wed, 03 Oct 2012 04:50:58 +0930 From: Shane Ambler <FreeBSD@ShaneWare.Biz> To: FreeBSD-ports <freebsd-ports@freebsd.org> Cc: gerald@freebsd.org Subject: Possible regression in i386 build with gcc 4.6 Message-ID: <506B3E9A.1000905@ShaneWare.Biz>
next in thread | raw e-mail | index | archive | help
I found a situation where gcc v4.2 compiles a i386 working binary and
v4.6 doesn't. (Currently 4.7 and 4.8 fail to build this code) I have
verified that this happens with 8.2/8.3/9.0 i386 systems. x86_64
versions build without issue as does clang i386/x86_64.
It appears that the x86_64 target of gcc offers gcc atomics while the
i386 target doesn't - and this appears to be a freebsd specific setup,
the i386 targets then fall back to using tbb atomics.
Is this some subtle bug I'm missing? can it be alleviated with compiler
flags/more universal code?
I have tried to cut this down to just the call that triggers a
segmentation fault but the one call itself isn't enough.
The issue can be found in graphics/openimageio. The easiest way I know
to cause the segmentation fault is with the image viewer that is part of
the port (it is a Qt app) it seg faults during startup. There is no need
to open any images just starting iv with an empty window is fine.
The makefile is setup to USE_GCC=4.6+ for i386/8.2 - this is a leftover
from earlier versions that will be removed next update.
cd /usr/ports/graphics/openimageio
make
./work/.build/iv/iv
The error appears to stem from line 193 of src/libutil/ustring.cpp
atomic_exchange_and_add (&ustring_stats_constructed, 1);
Commenting this line prevents the crash but isn't a valid fix.
the relevant function it calls is -- src/include/thread.h:283
which uses the atomic class template from tbb for the i386 build.
inline long long
atomic_exchange_and_add (volatile long long *at, long long x)
{
#ifdef USE_GCC_ATOMICS
return __sync_fetch_and_add (at, x);
#elif USE_TBB
atomic<long long> *a = (atomic<long long> *)at;
return a->fetch_and_add (x);
#elif defined(__APPLE__)
<snip>
#endif
}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?506B3E9A.1000905>