On Mon, Sep 21, 2026 at 3:25 PM Matt Turner <[email protected]> wrote: > > On Mon, Sep 21, 2026 at 6:07 PM Andrea Pinski > <[email protected]> wrote: > > > > On Mon, Sep 21, 2026 at 2:50 PM Matt Turner <[email protected]> wrote: > > > > > > Using a cast as an lvalue in an asm output operand is a GCC extension. > > > Clang accepts it only with -fheinous-gnu-extensions. By default > > > -Winvalid-gnu-asm-cast is an error, so these blocks fail to build with > > > clang. > > > > Yes but this file should only be used for compiling target libraries > > and always with GCC. Can you explain what is going on with how they > > are compiling with clang here? > > This is the 3rd (or 4th time) someone wants to change this due to clang > > usage. > > How I got here is I noticed that libgcrypt fails to build with clang > due to casts on output parameters in longlong.h. I sent a patch [1] to > remove them. The patch was rejected [2] because > > """ > For longlong.h, the upstream used to be GNU C library. It is GCC now > (gcc/include/longlong.h). > > We don't want further differences of our own from upstream. > """
Actually upstream used to be GMP. And it is still is: https://github.com/gmp-mirror/gmp/blob/master/longlong.h Thanks, Andrea > > which is, IMO, pretty silly because they've only imported changes from > GCC once AFAICT and have a bunch of their own changes on top. > > If we don't want this, I'll go back to libgcrypt and propose a > configure.ac workaround for clang. > > [1] https://lists.gnupg.org/pipermail/gcrypt-devel/2026-September/006182.html > [2] https://lists.gnupg.org/pipermail/gcrypt-devel/2026-September/006219.html
