>
> How does the compiler know it doesn't depend on memory?
When it has no m (or equivalent like g) constrained argument
and no memory clobber.
> How do you say it depends on memory?
You add any of the above.
> You really need something as heavy as volatile?
You could do a memory clobber,
On Wednesday 03 October 2007 16:18, H. Peter Anvin wrote:
> Nick Piggin wrote:
> >> This should work because the result gets used before reading again:
> >>
> >> read_cr3(a);
> >> write_cr3(a | 1);
> >> read_cr3(a);
> >>
> >> But this might be reordered so that b gets read before the write:
> >>
>
Arjan,
I can experiment with any constraints if you suggest which one.
>From our experiments with gcc, it compares asm strings (sic!!!) to find matches
to be merged! Sigh...
Below are 2 programs which differ in one space in read_cr3_b() asm statement.
The first one compiles incorrectly, while 2nd
Nick Piggin wrote:
This should work because the result gets used before reading again:
read_cr3(a);
write_cr3(a | 1);
read_cr3(a);
But this might be reordered so that b gets read before the write:
read_cr3(a);
write_cr3(a | 1);
read_cr3(b);
?
I don't see how, as write_cr3 clobbers memory.
On Wednesday 03 October 2007 04:27, Chuck Ebbert wrote:
> On 10/02/2007 11:28 AM, Arjan van de Ven wrote:
> > On Tue, 02 Oct 2007 18:08:32 +0400
> >
> > Kirill Korotaev <[EMAIL PROTECTED]> wrote:
> >> Some gcc versions (I checked at least 4.1.1 from RHEL5 & 4.1.2 from
> >> gentoo) can generate inco
Arjan van de Ven wrote:
On Tue, 02 Oct 2007 18:08:32 +0400
Kirill Korotaev <[EMAIL PROTECTED]> wrote:
Some gcc versions (I checked at least 4.1.1 from RHEL5 & 4.1.2 from
gentoo) can generate incorrect code with read_crX()/write_crX()
functions mix up, due to cached results of read_crX().
I'm
On 10/02/2007 11:28 AM, Arjan van de Ven wrote:
> On Tue, 02 Oct 2007 18:08:32 +0400
> Kirill Korotaev <[EMAIL PROTECTED]> wrote:
>
>> Some gcc versions (I checked at least 4.1.1 from RHEL5 & 4.1.2 from
>> gentoo) can generate incorrect code with read_crX()/write_crX()
>> functions mix up, due to
On Tue, 02 Oct 2007 18:08:32 +0400
Kirill Korotaev <[EMAIL PROTECTED]> wrote:
> Some gcc versions (I checked at least 4.1.1 from RHEL5 & 4.1.2 from
> gentoo) can generate incorrect code with read_crX()/write_crX()
> functions mix up, due to cached results of read_crX().
>
I'm not so sure volatil
On Tuesday 02 October 2007 16:08:32 Kirill Korotaev wrote:
> Some gcc versions (I checked at least 4.1.1 from RHEL5 & 4.1.2 from gentoo)
> can generate incorrect code with read_crX()/write_crX() functions mix up,
> due to cached results of read_crX().
added thanks
-Andi
-
To unsubscribe from t
Some gcc versions (I checked at least 4.1.1 from RHEL5 & 4.1.2 from gentoo)
can generate incorrect code with read_crX()/write_crX() functions mix up,
due to cached results of read_crX().
The small app for x8664 below compiled with -O2 demonstrates this
(i686 does the same thing):
10 matches
Mail list logo