gcc and 128-bit compare/exchange

[Brian Inglis]

On 2020-03-12 16:49, Eliot Moss wrote:
> 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?

Just putting the background and options out there.

Everyone makes their own choices for their own reasons.
Many may choose like you did and I would do the same.

Someone may need it enough to make it work sometime.
The nature of volunteer projects is that when something itches badly enough, it
gets scratched.

Some student may think it's worth some effort to learn, contribute, do a paper,
to add to resume, or propose for a Google Summer of Coronavirus project or
similar, with university classes going online or pausing, as spring break and
summer jobs may now be questionable.

-- 
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.