On 07/07/2010 08:51 AM, Aldy Hernandez wrote:
> * configure.ac: Call LIBITM_CHECK_64BIT_SYNC_BUILTINS.
> * beginend.cc (begin_transaction): If 64-bit sync builtins are not
> available, use pthread mutexes.
> * acinclude.m4 (LIBITM_CHECK_64BIT_SYNC_BUILTINS): New.
> * c
> > ... a slightly more sophisticated variant of b) would be using
> > uint64_t for 64-bit targets and uint32_t for 32-bit targets, should
> > make everybody happy.
>
> There's a correctness issue in the library interface -- there's no
> clean way to handle that value overflowing. Rather than mak
On Fri, Feb 19, 2010 at 3:38 AM, Aldy Hernandez wrote:
> libitm.so won't build on ia32 because of an undefined reference to
> __sync_add_and_fetch_8.
>
> This is the build failure Pearly encountered here:
>
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01201.html
>
> What happens is that w
On 02/19/2010 04:18 AM, Paolo Carlini wrote:
> On 02/19/2010 01:07 PM, Paolo Carlini wrote:
>> On 02/19/2010 12:38 PM, Aldy Hernandez wrote:
>>
>>> Since the TM library on ia32 is built with -m486, which doesn't
>>> have 64-bit atomic operations, should we...
>>>
>>> a) Build with -m586 and above
On 02/19/2010 01:07 PM, Paolo Carlini wrote:
> On 02/19/2010 12:38 PM, Aldy Hernandez wrote:
>
>> Since the TM library on ia32 is built with -m486, which doesn't have
>> 64-bit atomic operations, should we...
>>
>> a) Build with -m586 and above.
>> b) Have _ITM_transactionId_t be 32-bi
On 02/19/2010 12:38 PM, Aldy Hernandez wrote:
> Since the TM library on ia32 is built with -m486, which doesn't have
> 64-bit atomic operations, should we...
>
> a) Build with -m586 and above.
> b) Have _ITM_transactionId_t be 32-bit quantities.
> c) Come up with some locking solu
