Messages in this thread | | | Date | Tue, 9 Dec 2003 08:44:08 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: const versus __attribute__((const)) |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |