From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: RE: [PATCH] MIPS64 atomic_arch.h Clang complains about input type
Date: Tue, 8 Mar 2016 19:11:57 +0100 [thread overview]
Message-ID: <20160308181156.GY29662@port70.net> (raw)
In-Reply-To: <20160308172650.GE9349@brightrain.aerifal.cx>
* Rich Felker (dalias@libc.org) <dalias@libc.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@imgtec.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
next prev parent reply other threads:[~2016-03-08 18:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-08 10:09 Jaydeep Patil
2016-03-08 11:26 ` Szabolcs Nagy
2016-03-08 17:26 ` Rich Felker (dalias@libc.org)
2016-03-08 18:11 ` Szabolcs Nagy [this message]
2016-03-09 5:00 Jaydeep Patil
2016-03-11 5:19 ` Rich Felker (dalias@libc.org)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160308181156.GY29662@port70.net \
--to=nsz@port70.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).