From owner-freebsd-ports@FreeBSD.ORG Sat Oct 6 15:46:55 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 AA323106566B; Sat, 6 Oct 2012 15:46:55 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by mx1.freebsd.org (Postfix) with ESMTP id D6FAE8FC0C; Sat, 6 Oct 2012 15:46:54 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAPpQcFDLevdH/2dsb2JhbABFu2GESYIgAQEEAScRQRALGAkTAw8JAwIBAgFFBg0BBwEBh3sFuSqLT4YQA4hWnUOCfYFT Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail06.adl6.internode.on.net with ESMTP; 07 Oct 2012 01:16:53 +0930 Message-ID: <507050BE.4050905@ShaneWare.Biz> Date: Sun, 07 Oct 2012 01:09:42 +0930 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120918 Thunderbird/15.0.1 MIME-Version: 1.0 To: Tijl Coosemans References: <506B3E9A.1000905@ShaneWare.Biz> <506EEA7C.2020307@coosemans.org> In-Reply-To: <506EEA7C.2020307@coosemans.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 06 Oct 2012 15:46:55 -0000 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. >> 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 *a = (atomic *)at; >> return a->fetch_and_add (x); >> #elif defined(__APPLE__) >> >> #endif >> } > > Atomic operations on long long require cmpxchg8b instruction which was > added to the i586, so if you add -march=i586 to CFLAGS you should be > able to use gcc atomics on FreeBSD/i386 as well. > 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 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. 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.