From owner-freebsd-ports@FreeBSD.ORG Wed Oct 3 10:56:04 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 292A5106564A; Wed, 3 Oct 2012 10:56:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B7BE58FC08; Wed, 3 Oct 2012 10:56:02 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q93Au0jp089533; Wed, 3 Oct 2012 13:56:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q93AtmhM067796; Wed, 3 Oct 2012 13:55:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q93Atm25067795; Wed, 3 Oct 2012 13:55:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Oct 2012 13:55:48 +0300 From: Konstantin Belousov To: Shane Ambler Message-ID: <20121003105547.GS35915@deviant.kiev.zoral.com.ua> References: <506B3E9A.1000905@ShaneWare.Biz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWAGJYLEitsbNOt2" Content-Disposition: inline In-Reply-To: <506B3E9A.1000905@ShaneWare.Biz> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: gerald@freebsd.org, FreeBSD-ports Subject: Re: Possible regression in i386 build with gcc 4.6 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 10:56:04 -0000 --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 *a =3D (atomic *)at; > return a->fetch_and_add (x); > #elif defined(__APPLE__) > > #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--