X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
Subject:	Re: gcc and 128-bit compare/exchange
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
References:	<ab69ca04-06a2-eeb9-4771-e37432b59a77 AT cs DOT umass DOT edu>
	<f27b324f-049c-7830-68cd-14813aab6eed AT cs DOT umass DOT edu>
	<66f51c13-4c87-3bd6-3b8e-01901155ef2a AT SystematicSw DOT ab DOT ca>
	<de26ff04-596e-1dad-f2ae-4b91ba53f5c1 AT cs DOT umass DOT edu>
	<0a2c77b2-7ff2-8118-8631-29d186184ad9 AT SystematicSw DOT ab DOT ca>
From:	Eliot Moss <moss AT cs DOT umass DOT edu>
Message-ID:	<0fc8a150-99b1-34dc-0dfb-a096fc3b2096@cs.umass.edu>
Date:	Wed, 11 Mar 2020 02:13:40 -0400
User-Agent:	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
	Thunderbird/68.5.0
MIME-Version:	1.0
In-Reply-To:	<0a2c77b2-7ff2-8118-8631-29d186184ad9@SystematicSw.ab.ca>
X-Spam-Status:	No, score=-1.9 required=5.0 tests=BAYES_00, SPF_HELO_NONE,
	SPF_PASS autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version:	SpamAssassin 3.4.2 (2018-09-13) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	Cygwin mailing list <cygwin.cygwin.com>
List-Unsubscribe:	<http://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<http://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<http://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Reply-To:	moss AT cs DOT umass DOT edu
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 02B6ED7q027397

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 inline cmpxchg16b isn't.
> 
> Doing what you're doing now seems easier and better supported than alternatives.
> You can drop stdatomic.h and -latomic as the low level functions are builtins.
> 
> You could also write your own inline function using cmpxchg16b directly in asm.
> 
> Looks like because of cpu and library requirements, you would have to enable
> indirect inline functions in gcc, write libatomic library functions which
> support gcc indirect inline functions, to test cpu cx16 feature, then setup
> indirection, to bypass mutexes.

There are two issues here:

1) Whether the call is inlined.

2) Whether I get the compare-exchange instruction or a block of code protected
    by a pthread mutex.

The __atomic functions do not inline, as far as I know, from my testing on true
Linux platforms.  But Linux _does_ give me the compare-exchange version of
the function.

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 libatomic / libc are not delivering the desired
version of the atomic compare-exchange function.

My _guess_ is that having that as an option depends somehow on how gcc is built,
e.g., its build configuration.  I don't know enough about how those ifunc mechanisms
work to know if that is it, or if it's something else, but the behavior seems to
be Cygwin-specific.  Hence my report.

Regards - Eliot
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -