On Thu, Apr 4, 2013 at 12:40 PM, David Rientjes <rientjes@xxxxxxxxxx> wrote:
>
> I said in the previous email that you'd do this solely to rely on a
> well-defined semantic rather than reading paragraphs of comments that
> we're developing.
What's "well-defined" about it? It's implementation-defined in both cases.
IOW, why do you think "__builtin_access_once(x)" is fundamentally
different from "(*(volatile type *)&(x))"? Both would be equally
dependent on the compiler implementation, and I'd argue that it would
be much nicer if gcc just automatically turned the existing volatile
code internally into the builtin version (and then didn't even bother
to expose that builtin), since if they are willing to do the built-in,
they clearly acknowledge the need for this kind of behavior in the
first place.
See what I'm arguing? If a compiler writer is acknowledging that this
kind of "access once with good semantics through a pointer" is needed
and useful (and in the presense of IO and threading, a compiler writer
that doesn't acknowledge that is a moron), then _why_ would that same
compiler writer then argue against just doing that for volatile
pointers?
What's so magically bad about "volatile" that would be solved by a
totally new and nonstandard builtin?
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>