On 2020-03-12 16:49, Eliot Moss wrote:
> On 3/12/2020 5:13 PM, Brian Inglis wrote:
>> On 2020-03-11 21:36, Eliot Moss wrote:
>>> On 3/11/2020 12:30 PM, Brian Inglis wrote:
On 2020-03-11 00:13, Eliot Moss wrote:
> On 3/11/2020 1:31 AM, Brian Inglis wrote:
>>>
There are gcc bugzilla com
On 3/12/2020 5:13 PM, Brian Inglis wrote:
On 2020-03-11 21:36, Eliot Moss wrote:
On 3/11/2020 12:30 PM, Brian Inglis wrote:
On 2020-03-11 00:13, Eliot Moss wrote:
On 3/11/2020 1:31 AM, Brian Inglis wrote:
There are gcc bugzilla comments about requiring gcc to be built with glibc
libatomic t
On 2020-03-11 21:36, Eliot Moss wrote:
> On 3/11/2020 12:30 PM, Brian Inglis wrote:
>> On 2020-03-11 00:13, Eliot Moss wrote:
>>> On 3/11/2020 1:31 AM, Brian Inglis wrote:
>
>> There are gcc bugzilla comments about requiring gcc to be built with glibc
>> libatomic to guarantee indirect inline func
On 3/11/2020 12:30 PM, Brian Inglis wrote:
On 2020-03-11 00:13, Eliot Moss wrote:
On 3/11/2020 1:31 AM, Brian Inglis wrote:
There are gcc bugzilla comments about requiring gcc to be built with glibc
libatomic to guarantee indirect inline functions support, and presumably glibc
detecting gcc i
Eliot Moss writes:
> What I am really reporting is that Cygwin is giving the pthread mutex form
> when it should not be. My CPU clearly has the capability, and the compiler
> clearly
> knows how to emit the instruction, since the __sync form does it. What is
> mysterious and tangled is why libat
On 2020-03-11 00:13, Eliot Moss wrote:
> On 3/11/2020 1:31 AM, Brian Inglis wrote:
>
> A quick followup: I was able to get __sync_val_compare_and_swap_16 to work
> (and its bool form). That will do for now, though of course it's
> deprecated.
>
> This does get me the inlined asm cod
On 3/11/2020 1:31 AM, Brian Inglis wrote:
A quick followup: I was able to get __sync_val_compare_and_swap_16 to work
(and its bool form). That will do for now, though of course it's deprecated.
This does get me the inlined asm code.
Digging further into the murk where a simple builtin inlin
On 2020-03-10 15:13, Eliot Moss wrote:
> On 3/10/2020 4:35 PM, Brian Inglis wrote:
>> On 2020-03-08 20:59, Eliot Moss wrote:
>>> On 3/8/2020 10:29 PM, Eliot Moss wrote:
This is probably to the gcc maintainer ...
I am running on a processor that has compare/exchange 128-bit (cx16
On 3/10/2020 4:35 PM, Brian Inglis wrote:
On 2020-03-08 20:59, Eliot Moss wrote:
On 3/8/2020 10:29 PM, Eliot Moss wrote:
This is probably to the gcc maintainer ...
I am running on a processor that has compare/exchange 128-bit (cx16 capability),
and I compiler with -mcx16 and -latomic. I'm on
On 2020-03-08 20:59, Eliot Moss wrote:
> On 3/8/2020 10:29 PM, Eliot Moss wrote:
>> This is probably to the gcc maintainer ...
>>
>> I am running on a processor that has compare/exchange 128-bit (cx16
>> capability),
>> and I compiler with -mcx16 and -latomic. I'm on the latest release cygwin
>>
On 3/8/2020 10:29 PM, Eliot Moss wrote:
This is probably to the gcc maintainer ...
I am running on a processor that has compare/exchange 128-bit (cx16 capability),
and I compiler with -mcx16 and -latomic. I'm on the latest release cygwin gcc
(9.2.0-3, I believe) and the corresponding libatomic.
This is probably to the gcc maintainer ...
I am running on a processor that has compare/exchange 128-bit (cx16 capability),
and I compiler with -mcx16 and -latomic. I'm on the latest release cygwin gcc
(9.2.0-3, I believe) and the corresponding libatomic. I have a program with
this in it:
__at
12 matches
Mail list logo
