|
Message-ID: <20160308181156.GY29662@port70.net> Date: Tue, 8 Mar 2016 19:11:57 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: RE: [PATCH] MIPS64 atomic_arch.h Clang complains about input type * Rich Felker (dalias@...c.org) <dalias@...c.org> [2016-03-08 12:26:50 -0500]: > On Tue, Mar 08, 2016 at 12:26:13PM +0100, Szabolcs Nagy wrote: > > * Jaydeep Patil <Jaydeep.Patil@...tec.com> [2016-03-08 10:09:43 +0000]: > > > > > > ./arch/mips64/atomic_arch.h:37:29: error: unsupported inline asm: input with type 'long *' matching output with type 'int' > > > > > > > clang probably should not complain about this > > > > (it's possible to have the output in the low 32bit of a 64bit input reg > > and then you do want mismatching input/output types for the same reg) > > I can imagine it being problematic on other archs where the register > names are different for 32-bit and 64-bit versions -- %0 couldn't > expand to both. Isn't there a similar ugly issue on aarch64's > atomic_arch.h? > in aarch64 asm wN is the 32bit part of gpr N and xN is the whole 64bit. (width is not part of the mnemonics, but the operands in most cases). in gcc inline asm %w0 prints wN and %x0 prints xN for gpr operands, plain %0 is the same as %x0 for gprs but works for other operands too. aarch64 gcc does not complain if you pass int for a 64bit operand or long for 32bit one (that's why we had a bug in atomic_arch.h, i forgot the 'w'), but this sdc input-output operand would work. > > > #define a_sc_p a_sc_p > > > -static inline int a_sc_p(volatile long *p, void *v) > > > +static inline void *a_sc_p(volatile long *p, void *v) > > > { > > > - int r; > > > + void *r; > > > __asm__ __volatile__ ( > > > "scd %0, %1" > > > : "=r"(r), "=m"(*p) : "0"(v) : "memory"); > > > > the return type should be int (1 on success, 0 on failure) > > > > e.g. you can use 'long r' instead of 'int r' > > > > if clang still complains then maybe > > > > union {void *v; long r;} u = {v}; > > __asm__ __volatile__ ( > > "scd %0, %1" : "+r"(u.v), "=m"(*p) :: "memory"); > > return u.r; > > If simply using 'long' works, I think that's the cleanest/simplest > solution. The union is uglier and less obvious what it's doing so I'd > rather avoid it if we can. > > Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.