[EMAIL PROTECTED] said:
> I tried it with two compilers, one older than yours and one newer:
> In both cases, the memory read occurs before "zzz".
[EMAIL PROTECTED] said:
> I guess Alexey point is that the current compiler doesn't notice
> that.
I don't understand why we're bringing
[EMAIL PROTECTED] said:
I tried it with two compilers, one older than yours and one newer:
In both cases, the memory read occurs before "zzz".
[EMAIL PROTECTED] said:
I guess Alexey point is that the current compiler doesn't notice
that.
I don't understand why we're bringing empirical
Andrea Arcangeli wrote:
> >int *p;
> >int func()
> >{
> > int x;
> > x = *p;
> > __asm__ __volatile__ ("" : : : "memory");
> > x = *p;
> > return x;
> >}
>
> Defintely none difference here (-fstrict-aliasing doesn't change anything
> either).
>
> andrea@inspiron:~ > gcc -v
> Reading specs
Andrea Arcangeli wrote:
> Said that if your compiler puts the read before the spin_lock without the
> memory clobber, it is allowed to do that, and in such case you would proof
> it was a real world bug (not just a "documentation" one).
Yes, it does.
> Or maybe your testcase was a bit different
Linus Torvalds wrote:
> Nope. "memory" fills that role too. Remember: "memory" doesn't actually
> say "this clobbers all memory". That would be silly: an asm that just
> wipes all memory would not be a very useful asm (or rather, it would have
> just _one_ use: "execve()"). So "memory" really
Linus Torvalds wrote:
> Change it to something like
>
> __asm__("":"=r" (x):"0" (x));
>
> and the "volatile" should matter.
Yes it does. Without "volatile", the asm disappears :-)
> Not for memory references, perhaps. But for the movement issues.
The compiler isn't moving memory
Linus Torvalds wrote:
> "volatile" should be equivalent to clobbering memory, although the gcc
> manual pages are certainly not very verbose on the issue.
It isn't. Try the following with/without the memory clobber:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : :
Andrea Arcangeli wrote:
> >>int a = *p;
> >>__asm__ __volatile__("" : :);
> >>a = *p;
> >>
> >> (to do two explicit reads)
> >
> >Sorry, that does just one read, kgcc (old stable gcc) and also with
> >gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
>
> I
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
> Maybe we can rely on the __volatile__ statement of the asm that will
> enforce that if we write:
>
> *p = 0;
> __asm__ __volatile__("" : :);
> *p = 1;
>
> in the assembler we'll
At 17:03 07.09.00, Andrea Arcangeli wrote:
>On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>
> >barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
> >"memory".
>
>I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
>memory (it looks necessary to make sure
Andrea Arcangeli wrote:
int a = *p;
__asm__ __volatile__("" : :);
a = *p;
(to do two explicit reads)
Sorry, that does just one read, kgcc (old stable gcc) and also with
gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
I wrote the above not
Linus Torvalds wrote:
"volatile" should be equivalent to clobbering memory, although the gcc
manual pages are certainly not very verbose on the issue.
It isn't. Try the following with/without the memory clobber:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : :
Linus Torvalds wrote:
Change it to something like
__asm__("":"=r" (x):"0" (x));
and the "volatile" should matter.
Yes it does. Without "volatile", the asm disappears :-)
Not for memory references, perhaps. But for the movement issues.
The compiler isn't moving memory references
Linus Torvalds wrote:
Nope. "memory" fills that role too. Remember: "memory" doesn't actually
say "this clobbers all memory". That would be silly: an asm that just
wipes all memory would not be a very useful asm (or rather, it would have
just _one_ use: "execve()"). So "memory" really says
At 17:03 07.09.00, Andrea Arcangeli wrote:
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure the
Andrea Arcangeli wrote:
Said that if your compiler puts the read before the spin_lock without the
memory clobber, it is allowed to do that, and in such case you would proof
it was a real world bug (not just a "documentation" one).
Yes, it does.
Or maybe your testcase was a bit different
Andrea Arcangeli wrote:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : : "memory");
x = *p;
return x;
}
Defintely none difference here (-fstrict-aliasing doesn't change anything
either).
andrea@inspiron:~ gcc -v
Reading specs from
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
Maybe we can rely on the __volatile__ statement of the asm that will
enforce that if we write:
*p = 0;
__asm__ __volatile__("" : :);
*p = 1;
in the assembler we'll then
On Tue, 29 Aug 2000, Andrea Arcangeli wrote:
>I'd prefer to have things like UnlockPage implemented as the architecture
>prefers (with a safe SMP common code default) instead of exporting zillons
I changed idea. I'd preferred to implement a mechanism that allows to
implement common code taking
On Tue, 29 Aug 2000, Andrea Arcangeli wrote:
I'd prefer to have things like UnlockPage implemented as the architecture
prefers (with a safe SMP common code default) instead of exporting zillons
I changed idea. I'd preferred to implement a mechanism that allows to
implement common code taking
20 matches
Mail list logo
