Possible regression in i386 build with gcc 4.6
tijl at coosemans.org
Sun Oct 7 22:10:27 UTC 2012
On 02-10-2012 21:20, Shane Ambler wrote:
> 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)
> #ifdef USE_GCC_ATOMICS
> return __sync_fetch_and_add (at, x);
> #elif USE_TBB
> atomic<long long> *a = (atomic<long long> *)at;
This cast is dangerous. It looks like atomic<long long> has 8 byte
alignment, but long long on i386 only has 4 byte alignment.
> return a->fetch_and_add (x);
> #elif defined(__APPLE__)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20121007/bf6e64c1/signature.pgp
More information about the freebsd-ports