delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
X-Original-To: | cygwin AT cygwin DOT com |
Delivered-To: | cygwin AT cygwin DOT com |
From: | Achim Gratz <Stromeko AT nexgo DOT de> |
To: | cygwin AT cygwin DOT com |
Subject: | Re: gcc and 128-bit compare/exchange |
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> | |
<0fc8a150-99b1-34dc-0dfb-a096fc3b2096 AT cs DOT umass DOT edu> | |
Date: | Wed, 11 Mar 2020 18:31:26 +0100 |
In-Reply-To: | <0fc8a150-99b1-34dc-0dfb-a096fc3b2096@cs.umass.edu> (Eliot Moss's |
message of "Wed, 11 Mar 2020 02:13:40 -0400") | |
Message-ID: | <87imjalrwx.fsf@Rainer.invalid> |
User-Agent: | Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
MIME-Version: | 1.0 |
X-VADE-STATUS: | LEGIT |
X-Spam-Status: | No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, |
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> | |
Errors-To: | cygwin-bounces AT cygwin DOT com |
Sender: | "Cygwin" <cygwin-bounces AT cygwin DOT com> |
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 libatomic / libc are not delivering the desired > version of the atomic compare-exchange function. Assuming you want to use a library, it would have to detect this capability at runtime (unless you force-build for a single CPU architecture) and dispatch different code based on the result. It's probably the latter part that's missing on Cygwin. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |