Re: 2.6.1-mm5 versus gcc 3.5 snapshot

[Richard Henderson]

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~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/