lkml.org 
[lkml]   [2003]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.070 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site