On 12/12/22 20:52, Segher Boessenkool wrote:
> On Mon, Dec 12, 2022 at 02:10:16PM -0300, Adhemerval Zanella Netto wrote:
>> On 30/11/22 20:24, Segher Boessenkool wrote:
>>> I understand that the casts should be no-ops on the asm side (maybe they
>>> change the sign) and they are present as type-checking.  Can we implement
>>> this type-checking in a different (portable) way?  I think the macro you use
>>> should be named like __asm_output_check_type (..) or so to indicate the
>>> intended purpose.
> 
> I didn't write that.  Please quote correctly.  Thanks!
> 
>> I do not think trying to leverage it on clang side would yield much, it
>> seems that it really does not want to support this extension.  I am not
>> sure we can really make it portable, best option I can think of would to
>> add a mix of __builtin_classify_type and typeof prior asm call (we do
>> something similar to powerp64 syscall code on glibc), although it would
>> still require some gcc specific builtins.
>>
>> I am open for ideas, since to get this header to be clang-compatible on
>> glibc it requires to get it first on gcc.
> 
> How do you intend to modify all the existing copies of the header that
> haven't been updated for over a decade already?> 
> If you think changing all user code that uses longlong.h is a good idea,
> please change it to not use inline asm, use builtins in some cases but
> mostly just rewrite things in plain C.  But GCC cannot rewrite user code
> (not preemptively anyway ;-) ) -- and longlong.h as encountered in the
> wild (not the one in our libgcc source code) is user code.
> 
> If you think changing the copy in libgcc is a good idea, please change
> the original in glibc first?

That's my original intention [1], but Joseph stated that GCC is the upstream
source of this file.  Joseph, would you be ok for a similar patch to glibc
since gcc is reluctant to accept it?

[1] https://sourceware.org/pipermail/libc-alpha/2022-October/143050.html

Reply via email to