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, Brian Inglis References:

<66f51c13-4c87-3bd6-3b8e-01901155ef2a AT SystematicSw DOT ab DOT ca> From: Eliot Moss Message-ID: Date: Tue, 10 Mar 2020 17:13:56 -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: <66f51c13-4c87-3bd6-3b8e-01901155ef2a@SystematicSw.ab.ca> Content-Language: en-US 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 Precedence: list List-Id: Cygwin mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 02ALETMN010505 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 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. > > You just needed to go to the next info page: > > $ info gcc __atomic > > and use: > > #include > extern bool __atomic_compare_exchange ( TYPE *ptr, > TYPE *expected, > TYPE *desired, > bool weak, > int success_memorder, > int failure_memorder); > > or higher level macro: > > atomic_compare_exchange_strong(PTR, VAL, DES) > > defined in /lib/gcc/x86_64-pc-cygwin/*/include/stdatomic.h That is what I was already doing :-) .... it compiles and runs, landing at libat_compare_exchange_16, which uses mutexes, not the 16-byte compare-exchange instruction. So how do I get the compare- exchange instruction to be used in the library? Regards - EM -- 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