From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) by sourceware.org (Postfix) with ESMTPS id 8258E387700C for ; Wed, 11 Mar 2020 16:30:02 +0000 (GMT) Received: from [192.168.1.114] ([24.64.172.44]) by shaw.ca with ESMTP id C4F6jf53n17ZDC4F7jGAdf; Wed, 11 Mar 2020 10:30:01 -0600 X-Authority-Analysis: v=2.3 cv=ZsqT1OzG c=1 sm=1 tr=0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=75eBEQDrEwwfkCEvCXMA:9 a=QEXdDO2ut3YA:10 Reply-To: cygwin@cygwin.com Subject: Re: gcc and 128-bit compare/exchange To: cygwin@cygwin.com References: <66f51c13-4c87-3bd6-3b8e-01901155ef2a@SystematicSw.ab.ca> <0a2c77b2-7ff2-8118-8631-29d186184ad9@SystematicSw.ab.ca> <0fc8a150-99b1-34dc-0dfb-a096fc3b2096@cs.umass.edu> From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual; keydata= mQENBFg15Q0BCADc1LTYJN/oVKOJoXpIo+5yy+sBv535qYNRh5CFqp3pPZwIy6oILNKprWph 8J+sXMqYd5H0G1jMDlXendiQbn9SiORuqI7xkV8vzguoFEMhNTxnO1pOQjqRnEnG/W7/5Yy+ DkcCv+Y4O3NX3wol8yP+FaEx4EEEifaO5ZhC1U/ilvHvxE0wjNhRG6AqlvqX6J09bxkJC8Xd 00MZWotDHtiq/wnd8YqyDmf0aJceGxSetHnqn/Cs3WiylEEUy2x/FqKbsBxUJHGQeeRTFAW1 ii08djCemxdE+romE/M9J9CVisSZImbXMSilX6Z2Qtz0lYPkY0EqbiKo8o9zlkIPhaqJABEB AAG0REJyaWFuIEluZ2xpcyAoU3lzdGVtYXRpYyBTb2Z0d2FyZSkgPEJyaWFuLkluZ2xpc0BT eXN0ZW1hdGljU1cuYWIuY2E+iQFVBBMBAgA/AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIX gBYhBEy/sJ49FaN/AfIQJjY9ewCxhxqTBQJai9F5BQkNRMzsAAoJEDY9ewCxhxqThnAH/Rau 2+nxwRYdOHDkvMJSyJZUxowkxxzfttQVfxrZIhooF99LGqd3ANltSidybJAbKDLoH+5jRvWF fobzOs93Uw73/52Rurv0nY40mnCAw2vE3JNYgWm8V09Ff4J64ElylrAAU60XoUxMD8Tbflby fVu3LO74pR/hCByNGK019TXJhIPfSU51hXQwLgqAKT4FRGw5gYyqCSS5zoRpa/zNENAPKG/g 5H8ar58eJB9QyJA4iNTLa/3rPF/kO9MqfRLlBLvmyveyYOcGs5wOgjt/RT2eA3Zun18l7EIE 2L2J1tbqLmSpswSW3URnW3KsfgILNC9pAVR00xvO09ulrUXiOX65AQ0EWDXlDQEIAM5GX98w WEzP1jyuWGfNI0s2lUJDTVH1WLpg1N+lQ9sjwCVBeJEdhtZYU7VsgmjPj+H0tkBFYe2olAkk BAmdP7yrqUTK5zw12kf5BJeF94cikGcFRCvdGVk9/uSfy3HZePvr8NV5LPCxLIE6bJCS8L5A CgdNkrD3CLM1zePyiQ0dQ3+6Bjq27b3Y1UauiyKlOquCVkfrDk/y3OfFhbiJX8pwM0mICyls 8p9iM7yg+g1PbdoA99OrFc7JKllHRGDLQ0B/HKAPgNnLCenzDuV/d+N1RDbbpa0c/uvmoptR Aejlq3HszXYQ9wTmu8OwVSITSkzgP1lKzyDPZS9SGvlrQp8AEQEAAYkBPAQYAQIAJgIbDBYh BEy/sJ49FaN/AfIQJjY9ewCxhxqTBQJai9GnBQkNRM0aAAoJEDY9ewCxhxqTuL8H/ivw0VXX lQW4c9O8XsMafDcEyV23MH4fdZACss+ZWluda7xIRo78GCLXxARHwJdOE9Jk9+/fDQOTZd4m KW0trLCfWvJnwNJfOLbqse7eydvgdj2UrTpy4DO/5+mAw/ilgZpEGgwMwyqb/2kFiKK7Q64B NKl8Y2kRXltaiXfqyvG2U/NiE4GOPA3yZgXs4Mzd1pzV/nkEIzGkneaeE5WGEWj/8dCnn6a3 zIuq0L59QInxKsTdt10OQiUoRKl8Nx0vDCOzMy0wlJc349gJbQBCAZcumtBBBqAzCAmJ3J7T 7ew8hznAEmOwr+LkSOdXFzEjdfTaryhN1AsRLYVUNloEWNA= Organization: Systematic Software Message-ID: <314e9077-6e0a-70cc-5b31-4fab2c755581@SystematicSw.ab.ca> Date: Wed, 11 Mar 2020 10:30:00 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <0fc8a150-99b1-34dc-0dfb-a096fc3b2096@cs.umass.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfOBUKHyC+fBnQVTbf2qJpQZhe2lZWCz6GdEVyDppjsFf9vPUGdQY4ZzH7uymKBWBAewusZh2C0gfHCwxzjTd6oV92R29doSiIJfc3v0Pz1/8kaLHNIm5 +dZwPBJMXAm8QO9HAmvTvv4K9AtxK/57ep0nR44YBwQEeGYmOq+sXjTLDSbUIR+LG2QgzdL6U21BKA== X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 16:30:03 -0000 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 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. 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 indirect inline functions support, and not supporting other libc variants including musl, newlib, uclibc, etc. The problem is that newlib is BSD licensed and glibc is GPL and you can not contaminate newlib by looking at or including GPL code, although you may be able to do so in the Cygwin winsup library. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.