Date: Wed, 3 Oct 2012 13:55:48 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Shane Ambler <FreeBSD@ShaneWare.Biz> Cc: gerald@freebsd.org, FreeBSD-ports <freebsd-ports@freebsd.org> Subject: Re: Possible regression in i386 build with gcc 4.6 Message-ID: <20121003105547.GS35915@deviant.kiev.zoral.com.ua> In-Reply-To: <506B3E9A.1000905@ShaneWare.Biz> References: <506B3E9A.1000905@ShaneWare.Biz>
next in thread | previous in thread | raw e-mail | index | archive | help
--pWAGJYLEitsbNOt2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
>=20
> 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.
>=20
> Is this some subtle bug I'm missing? can it be alleviated with compiler
> flags/more universal code?
>=20
> I have tried to cut this down to just the call that triggers a
> segmentation fault but the one call itself isn't enough.
>=20
> 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.
>=20
> The makefile is setup to USE_GCC=3D4.6+ for i386/8.2 - this is a leftover
> from earlier versions that will be removed next update.
>=20
> cd /usr/ports/graphics/openimageio
> make
> ./work/.build/iv/iv
>=20
> The error appears to stem from line 193 of src/libutil/ustring.cpp
>=20
> atomic_exchange_and_add (&ustring_stats_constructed, 1);
>=20
> 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.
>=20
> 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 =3D (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=3D486. I think that the po=
rts
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.
--pWAGJYLEitsbNOt2
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)
iEYEARECAAYFAlBsGbMACgkQC3+MBN1Mb4hufwCgjWsh4Wr7h0tiVyWTBOI/YCJK
Cf0AoNWS5wEdEnW1zp2H+6WiZCgSbCAv
=8Cjm
-----END PGP SIGNATURE-----
--pWAGJYLEitsbNOt2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121003105547.GS35915>