Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 06 Oct 2012 18:54:41 +0200
From:      Tijl Coosemans <tijl@coosemans.org>
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:  <50706251.7070801@coosemans.org>
In-Reply-To: <507050BE.4050905@ShaneWare.Biz>
References:  <506B3E9A.1000905@ShaneWare.Biz> <506EEA7C.2020307@coosemans.org> <507050BE.4050905@ShaneWare.Biz>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA5DF7AB869ED21B54E01D351
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06-10-2012 17:39, Shane Ambler wrote:
> On 05/10/2012 23:41, Tijl Coosemans wrote:
>> 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.
>>>=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.
>>>
>>> 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
>>> }
>>
>> Atomic operations on long long require cmpxchg8b instruction which was=

>> added to the i586, so if you add -march=3Di586 to CFLAGS you should be=

>> able to use gcc atomics on FreeBSD/i386 as well.
>=20
> The arch setting isn't the issue - gcc compiled on freebsd for 32bit
> x86 target doesn't provide gcc atomics. So __sync_fetch_and_add
> doesn't exist. While adding support for gcc atomics to the i386
> target would be good, I would assume there is a reason that it is
> disabled on FreeBSD (that reason may or may not be resolved now).

The __sync built-ins exist in both base and ports gcc, but
__sync_fetch_and_add_8 needs at least -march=3Di586.

> The point I wanted to make in this email is that for some reason
> gcc46 compiles the tbb alternative in a way that causes a seg fault
> when gcc42 can compile it fine. And to maybe get the gcc atomics
> support re-evaluated.
>=20
> But you did give me an idea or two - the first of adding some asm
> code is beyond me but I then went and found that go-semacquire.c from
> gcc46 source has code for __sync_fetch_and_add_4 (using pthread mutex
> locks) so I used that to create a patch that gets the gcc46 build
> working.


--------------enigA5DF7AB869ED21B54E01D351
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iF4EAREIAAYFAlBwYlcACgkQfoCS2CCgtit5tAD/XZcG7f/jMQcCpQeHKLR40JR7
bymbZtEDHJNJfGAJDQEBAITB9WT4iwmU/4KfG1PzISh2eBCF5jJkVcMxkzYa08QC
=1EA3
-----END PGP SIGNATURE-----

--------------enigA5DF7AB869ED21B54E01D351--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50706251.7070801>