From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailsrv.cs.umass.edu (mailsrv.cs.umass.edu [128.119.240.136]) by sourceware.org (Postfix) with ESMTPS id 1EF83385F022 for ; Thu, 12 Mar 2020 03:36:57 +0000 (GMT) Received: from [10.28.58.21] (unknown [150.203.68.60]) by mailsrv.cs.umass.edu (Postfix) with ESMTPSA id B9463401C1A5; Wed, 11 Mar 2020 23:36:54 -0400 (EDT) Reply-To: moss@cs.umass.edu Subject: Re: gcc and 128-bit compare/exchange To: cygwin@cygwin.com, Brian Inglis 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> <314e9077-6e0a-70cc-5b31-4fab2c755581@SystematicSw.ab.ca> From: Eliot Moss Message-ID: <6247a9c3-88b1-2ed0-31eb-408d709f5897@cs.umass.edu> Date: Wed, 11 Mar 2020 23:36: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: <314e9077-6e0a-70cc-5b31-4fab2c755581@SystematicSw.ab.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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@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: Thu, 12 Mar 2020 03:36:57 -0000 On 3/11/2020 12:30 PM, Brian Inglis wrote: > On 2020-03-11 00:13, Eliot Moss wrote: >> On 3/11/2020 1:31 AM, Brian Inglis wrote: > 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. Hmm. Well, I just install standard stuff on Linux and then on Cygwin, and I see different behavior. I don't know how licenses come into that (I'm not saying they don't, only that it exceeds my knowledge). Are you saying that Cygwin's build of gcc is intended to work with other libraries in addition to glibc, and hence Cygwin's gcc might have been built without some stuff to avoid license contamination? It is probably not worth my while to do my own build of gcc just for this. I can just write my own wrapper for the __sync function. But it seemed wrong / broken to me that the __atomic builtin did not do what was expected. (Brian, are you the maintainer, or is there someone else with whom the conversation would be taken up? Regards - Eliot