Possible regression in i386 build with gcc 4.6

Konstantin Belousov kostikbel at gmail.com
Wed Oct 3 10:56:04 UTC 2012

On Wed, Oct 03, 2012 at 04:50:58AM +0930, 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
> 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)
> {
>      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
> }
The in-tree gcc is indeed defaults to the -march=486. I think that the ports
gcc lacks several customizations. At least we recently updates specs
to include both SysV and GNU hash tables, as well as enabled new dtags.
There are probably more small things.

The right solution, obviously, is to push these customizations into the
gcc source.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20121003/258d21fb/attachment.pgp

More information about the freebsd-ports mailing list