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. b) Have _ITM_transactionId_t be >>> 32-bit quantities. c) Come up with some locking solution for >>> archs that don't have 64-bit atomic operations. >>> >> My personal opinion on this is that unless we are 100% sure that >> performance are decent anyway (thus 3), or 32-bits are certainly >> enough (thus 2), we should not waste time supporting anything older >> than -m586 for the transactional memory work. >> > ... 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 make the library interface way more complex, it seemed far easier to simply use a 64-bit value, which we simply assume won't overflow. I'd be fine with -m586 (which is how things will get built on e.g. Fedora), but that isn't going to help other 32-bit targets that miss that operation. We'll need a configure test and a mutex if needed. r~
