Re: [PATCH] mark read_crX() asm code as volatile

2007-10-03 Thread Andi Kleen
> > 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,

Re: [PATCH] mark read_crX() asm code as volatile

2007-10-03 Thread Nick Piggin
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: > >> >

Re: [PATCH] mark read_crX() asm code as volatile

2007-10-03 Thread Kirill Korotaev
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

Re: [PATCH] mark read_crX() asm code as volatile

2007-10-02 Thread H. Peter Anvin
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.

Re: [PATCH] mark read_crX() asm code as volatile

2007-10-02 Thread Nick Piggin
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

Re: [PATCH] mark read_crX() asm code as volatile

2007-10-02 Thread H. Peter Anvin
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

Re: [PATCH] mark read_crX() asm code as volatile

2007-10-02 Thread Chuck Ebbert
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

Re: [PATCH] mark read_crX() asm code as volatile

2007-10-02 Thread Arjan van de Ven
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

Re: [PATCH] mark read_crX() asm code as volatile

2007-10-02 Thread Andi Kleen
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

[PATCH] mark read_crX() asm code as volatile

2007-10-02 Thread Kirill Korotaev
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):