Possible regression in i386 build with gcc 4.6

Shane Ambler FreeBSD at ShaneWare.Biz
Tue Oct 2 19:27:57 UTC 2012

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

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)
     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__)

More information about the freebsd-ports mailing list