Re: gcc and 128-bit compare/exchange

[Eliot Moss <moss@cs.umass.edu>]

On 3/12/2020 5:13 PM, Brian Inglis wrote:
> On 2020-03-11 21:36, Eliot Moss wrote:
>> 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?
> 
> All gccs allow building and working with any adequate libc including musl,
> newlib, uclibc, etc. but on Cygwin it is winsup for system stuff with newlib for
> generic stuff.
> 
> All I was pointing out was that while you could not copy LGPLed glibc libatomic
> code to BSD licensed newlib, you should be able to copy LGPLed glibc libatomic
> code to LGPLed Cygwin winsup libc, if you want to enable it with ifuncs,
> assuming they work under Windows.
> 
>> 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?
> 
> It's gcc maintainer (see announcement but post here), and base project
> committers for newlib (via newlib AT sourceware DOT org) and winsup (via cygwin
> DASH patches AT cygwin DOT com), ml archives in same place as Cygwin lists.

Thank you for the additional information.  At this point, I remain a little
unclear as to what you are suggesting my next step should be:

- Are you suggesting I do my own private build?
- Are you suggesting that I email those other lists?
- Are you thinking that the relevant maintainer would be reading this and that,
   for the moment, I should just wait for further response?

Regards - Eliot