On Friday 18 January 2008 05:54:12 am Andy Lutomirski wrote:
quoted text
> 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
--
unsubscribe notice
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/