Re: const versus __attribute__((const))

[Linus Torvalds <torvalds@osdl.org>]

On Tue, 9 Dec 2003, H. Peter Anvin wrote:
>
> In some ways, this is rather unfortunate, too.  What it really means is
> that the gcc "m" constraint is overloaded; it would have been better if
> they would have created a new modifier (say "*") for "must be lvalue."

The thing is, most users of "m" (like 99%) actually mean "_THIS_ memory
location". So just fixing the "m" modifier was an easy way to make sure
that users get the behaviour they expect.

Also, I have this dim memory of there actually being a potential bug in
"m" handling inside gcc, and requiring the entry to be a lvalue was the
easiest way to fix it. Richard Henderson would have the details.  I think
it was the liveness analysis that got confused or something.

And the thing is, if you have a non-lvalue right now, you will (a) get a
nice warnign that tells you so, and (b) it will be trivial to fix. So
something like

	asm("xxxx" : :"m" (1+x));

can be trivially fixed to be

	{
		int tmp = 1+x;
		asm("xxxx" : : "m" (tmp));
	}

so it's not like it's a horribly undue burden on the programmer.

In the kernel, I don't think we had a _single_ case that needed this, but
I might remember that wrong. Anyway, it wasn't a problem - and the kernel
tends to be the single most active user of inline asm's of all
gcc-compiled projects.

			Linus