On Friday 18 January 2008 05:54:12 am Andy Lutomirski wrote:
> It almost sounds like the compiler is free to change:
>
> void foo(const int *x);
> foo(x);
> printf("%d", x);
>
> to:
>
> void foo(const int *x);
> printf("%d", x);
> foo(x);
>
> especially if it can prove that the pointer to x doesn't otherwise
> escape or that foo doesn't call anything that could see the pointer (and
> given that gcc has special magical markings for malloc, one way this
> could be "proven" is to have x be some freshly malloced object.
That's absolutely not true.
Let's unravel the code, by fixing usage of 'x' (which seems to vary at will
between value and pointer in the above example), and by replacing printf with
another opaque function. Our decls:
void foo(const int *ptr);
void bar(int val);
You're saying that this:
foo(&x);
bar(x);
can be reordered into this:
bar(x);
foo(&x);
No way. First, the way that const is currently defined, the compiler cannot
assume that the value of x did not change while foo was executing. So, it
will not only be forced to leave the two functions in that order, it will
even reload the value of x before passing it into bar. Go figure.
Second, even if const did have stronger semantics that forbade the value of x
from being modified during execution of foo, the compiler still could not
reorder the two function calls, before it cannot assume that the two
functions (in their internal implementations) do not touch some other,
unknown to this code, global variable.
-- Vadim Lobanov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
