public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@twiddle.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Valdis.Kletnieks@vt.edu,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: 2.6.1-mm5 versus gcc 3.5 snapshot
Date: Wed, 21 Jan 2004 22:02:53 -0800	[thread overview]
Message-ID: <20040122060253.GA18719@twiddle.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0401212043200.2123@home.osdl.org>

On Wed, Jan 21, 2004 at 08:51:14PM -0800, Linus Torvalds wrote:
> > include/asm/rwsem.h:126: warning: read-write constraint does not allow
> > a register
> 
> To me that says "compiler on crack". I don't see why a register couldn't 
> be rw. After all, it clearly can be read, and written to, and gcc does 
> explicitly mention the '&' modifier in the documentation.
> 
> But maybe Richard has some input on what has happened, and can explain the 
> compiler side of it.. Richard?

You're reading that wrong way-round.  It's "+m" and "=m"/"0" that's
disallowed.  I.e. if you have matching constraints (or read-write
constrants, which are exactly short-hand for matching constraints),
then you *must* have a register alternative.  I.e. you'll get this
warning if you *only* allow memories.

The problem is partially conceptual -- what in the world does

	"=m"(x) : "0"(y)

mean?  Logically, this makes no sense.  The only way it can be resolved
is to create a new memory, copy y in, and copy x out.  But that violates
the lvalue promises we've made that make memory constraints useful for
atomic operations.

Partially it's implementation -- if you write

	"=m"(x) : "0"(x)

it *requires* that the optimizer be run and that it *must* identify the
common sub-expression.  Failure to do so means that the compiler has to
assume we have the x/y situation above, which of course results in a
diagnostic.

Obviously such a computational requirement is impossible with arbitrarily
complex expressions, so that begs the question of "how complex is too
complex".  Drawing an arbitrary line that you can explain to users is
impossible.  It is easier to simply disallow it entirely.

Finally, the whole thing is pointless.  Given the lvalue semantics, you
get *exactly* the same effect from

	"=m"(x) : "m"(x)

Since this works for any version of gcc, at any optimization level,
on any arbitrarily complex expression, we strongly recommend (ahem)
that code be modified to use this form.


r~

  reply	other threads:[~2004-01-22  6:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-21 22:36 2.6.1-mm5 versus gcc 3.5 snapshot Valdis.Kletnieks
2004-01-22  4:51 ` Linus Torvalds
2004-01-22  6:02   ` Richard Henderson [this message]
2004-01-22 15:27     ` Linus Torvalds
2004-01-22 23:30       ` Richard Henderson
2004-01-22 23:39         ` Linus Torvalds
2004-01-23  0:25           ` Richard Henderson

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=20040122060253.GA18719@twiddle.net \
    --to=rth@twiddle.net \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox