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
From: Eliot Moss <moss AT cs DOT umass DOT edu>
To: cygwin <cygwin AT cygwin DOT com>
References: <ab69ca04-06a2-eeb9-4771-e37432b59a77 AT cs DOT umass DOT edu>
Message-ID: <f27b324f-049c-7830-68cd-14813aab6eed@cs.umass.edu>
Date: Sun, 8 Mar 2020 22:59:51 -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: <ab69ca04-06a2-eeb9-4771-e37432b59a77@cs.umass.edu>
Content-Language: en-US
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE autolearn=unavailable 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
Precedence: list
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
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 029IpbXo015657

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.  I have a program with
> this in it:
> 
> __atomic_compare_exchange((__int128 *)&s1, (__int128 *)&z, (__int128 *)&s2, 0, __ATOMIC_SEQ_CST, 
> __ATOMIC_SEQ_CST);
> 
> This compiles to a call (nice if it would inline, but ...) to
> __atomic_compare_exchange_16, which uses mutex's, not the CMPXCHG16B
> instruction I was hoping for.  Note I am doing dynamic linking,
> which on at least one other platform results in dynamic selection
> of a lib_at implementation of the compare/exchange, which does use
> the desired instruction.
> 
> Is this a limitation of cygwin gcc, or should I be doing something
> different to achieve the desired effect?
> 
> Obviously it would be best not to going an asm inline if I can avoid it,
> but I suppose I can dig into the libatomic source to get the right
> incantation for it if need be ...

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.

Regards - EM
"--Problem reports:       http://cygwin.com/problems.htmlFAQ:                   http://cygwin.com/faq/Documentation:         http://cygwin.com/docs.htmlUnsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple"