On Fri, 8 Sep 2000, David Woodhouse wrote:
>[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 evidence into this
>discussion. Didn't we get into the horrible mess we've already got w.r.t.
I'm
On Fri, 8 Sep 2000, David Woodhouse wrote:
[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 evidence into this
discussion. Didn't we get into the horrible mess we've already got w.r.t.
I'm the
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>I tried it with two compilers, one older than yours and one newer:
So maybe I'm just been unlucky/lucky (depends on the point of view :) or
maybe we patched something I'm not aware of to make the kernel to compile
right.
>.ident "GCC: (GNU)
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Yes, it does.
Nice.
>.ident "GCC: (GNU) 2.96 2724 (experimental)"
>
>>From the Red Hat 7 beta.
Ok.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
On Thu, 7 Sep 2000, Jamie Lokier 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
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>
> It's ok for the compiler to do that (given we don't know what "volatile"
> means anyway :-). But it does have implications for spin_lock:
> spin_lock must say that it clobbers memory.
Yup. We should just fix that.
Linus
-
To
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>
> ps. There is a _clobber_ for memory, but no way to say "this asm _reads_
> arbitrary memory". __volatile__ may be filling that role though.
Nope. "memory" fills that role too. Remember: "memory" doesn't actually
say "this clobbers all memory". That
On Thu, 7 Sep 2000, Jamie Lokier wrote:
> 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__
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>asm *__volatile__* seems to make no difference. I've tried a few things.
It makes a difference, see below.
>
>Andrea Arcangeli wrote:
>> Maybe we can rely on the __volatile__ statement of the asm that will
>> enforce that if we write:
>>
>> *p =
On Thu, 7 Sep 2000, 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
On Thu, 7 Sep 2000, Franz Sirl wrote:
>In short terms:
>
>- __volatile__ assures that the code isn't reordered against other
>__volatile__ and isn't hoisted out of loops, nothing else
>- the "memory" clobber makes sure the asm isn't reordered against other
>memory accesses
Ok. That's all I
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 compiler doesn't delay to
write data to the
On Thu, 7 Sep 2000, Jamie Lokier wrote:
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__("" : :);
On Thu, 7 Sep 2000, Jamie Lokier wrote:
It's ok for the compiler to do that (given we don't know what "volatile"
means anyway :-). But it does have implications for spin_lock:
spin_lock must say that it clobbers memory.
Yup. We should just fix that.
Linus
-
To
On Thu, 7 Sep 2000, 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
On Thu, 7 Sep 2000, Franz Sirl wrote:
In short terms:
- __volatile__ assures that the code isn't reordered against other
__volatile__ and isn't hoisted out of loops, nothing else
- the "memory" clobber makes sure the asm isn't reordered against other
memory accesses
Ok. That's all I wanted
On Thu, 7 Sep 2000, Jamie Lokier 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
On Thu, 7 Sep 2000, Jamie Lokier wrote:
Yes, it does.
Nice.
.ident "GCC: (GNU) 2.96 2724 (experimental)"
From the Red Hat 7 beta.
Ok.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
On Thu, 7 Sep 2000, Jamie Lokier wrote:
I tried it with two compilers, one older than yours and one newer:
So maybe I'm just been unlucky/lucky (depends on the point of view :) or
maybe we patched something I'm not aware of to make the kernel to compile
right.
.ident "GCC: (GNU)
On Thu, 7 Sep 2000, Jamie Lokier wrote:
asm *__volatile__* seems to make no difference. I've tried a few things.
It makes a difference, see below.
Andrea Arcangeli wrote:
Maybe we can rely on the __volatile__ statement of the asm that will
enforce that if we write:
*p = 0;
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 compiler doesn't delay to
write data to the memory
21 matches
Mail list logo
