Yeah. Compiler errors are more annoying though I dare say ;-)
Actually, compile-time errors are fine,
Yes, they don't cause data corruption or anything like that,
but I still don't think the 390 people want to ship a kernel
that doesn't build -- and it seems they still need to support
GCC ver
On Sun, 12 Aug 2007, Segher Boessenkool wrote:
>
> Yeah. Compiler errors are more annoying though I dare say ;-)
Actually, compile-time errors are fine, and easy to work around. *Much*
more annoying is when gcc actively generates subtly bad code. We've had
use-after-free issues due to incorr
On Sun, 12 Aug 2007, Segher Boessenkool wrote:
>
> It works _most of the time_.
It used to have problems. Gcc has had problems in various areas.
> Ask Martin. Oh you don't even have to,
> he told you two mails ago. My last mail simply pointed out that this
> isn't a G
"+m" works. We use it. It's better than the alternatives. Pointing to
stale documentation doesn't change anything.
Well, perhaps on i386. I've seen some older versions of the s390 gcc
die
with an ICE because I have used "+m" in some kernel inline assembly.
I'm
happy to hear that this issue is
Yes, though I would use "=m" on the output list and "m" on the input
list. The reason is that I've seen gcc fall on its face with an ICE
on
s390 due to "+m". The explanation I've got from our compiler people
was
quite esoteric, as far as I remember gcc splits "+m" to an input
operand
and an out
Note that last line.
Segher, how about you just accept that Linux uses gcc as per reality,
and
that sometimes the reality is different from your expectations?
"+m" works.
It works _most of the time_. Ask Martin. Oh you don't even have to,
he told you two mails ago. My last mail simply po
On Sun, 12 Aug 2007, Martin Schwidefsky wrote:
>
> The duplication "=m" and "m" with the same constraint is rather
> annoying.
It's not only annoying, it causes gcc to generate bad code too. At least
certain versions of gcc will generate the address *twice*, even if there
is obviously only o
On Sat, 2007-08-11 at 23:09 -0700, Linus Torvalds wrote:
> Segher, how about you just accept that Linux uses gcc as per reality, and
> that sometimes the reality is different from your expectations?
>
> "+m" works. We use it. It's better than the alternatives. Pointing to
> stale documentation
On Sun, 2007-08-12 at 07:53 +0200, Segher Boessenkool wrote:
> > Yes, though I would use "=m" on the output list and "m" on the input
> > list. The reason is that I've seen gcc fall on its face with an ICE on
> > s390 due to "+m". The explanation I've got from our compiler people was
> > quite esot
On Sun, 12 Aug 2007, Segher Boessenkool wrote:
>
> Note that last line.
Segher, how about you just accept that Linux uses gcc as per reality, and
that sometimes the reality is different from your expectations?
"+m" works. We use it. It's better than the alternatives. Pointing to
stale documen
You'd have to use "+m".
Yes, though I would use "=m" on the output list and "m" on the input
list. The reason is that I've seen gcc fall on its face with an ICE on
s390 due to "+m". The explanation I've got from our compiler people was
quite esoteric, as far as I remember gcc splits "+m" to an i
On Thu, 2007-08-09 at 10:55 -0700, Linus Torvalds wrote:
> > You can use this forget() macro to make the compiler reread a variable:
> >
> > #define forget(var) asm volatile ("" : "=m"(var))
>
> No. That will also make the compiler "forget" any previous writes to it,
> so it changes behaviour.
>
On Thu, 9 Aug 2007, Chuck Ebbert wrote:
>
> You can use this forget() macro to make the compiler reread a variable:
>
> #define forget(var) asm volatile ("" : "=m"(var))
No. That will also make the compiler "forget" any previous writes to it,
so it changes behaviour.
You'd have to use "+m".
On Thu, 2007-08-09 at 13:36 -0400, Chuck Ebbert wrote:
> > Fair enough. Casting to (volatile int *) will give us the behavior
> > people expect when using atomic_t without needing to use inefficient
> > barriers.
> >
>
> You can use this forget() macro to make the compiler reread a
> variable:
>
On 08/09/2007 03:31 AM, Chris Snook wrote:
>
> Fair enough. Casting to (volatile int *) will give us the behavior
> people expect when using atomic_t without needing to use inefficient
> barriers.
>
You can use this forget() macro to make the compiler reread a variable:
#define forget(var) asm
On Thu, 9 Aug 2007, Jerry Jiang wrote:
>
> and still not to said "Why the *volatile-accesses-in-code* is
> acceptable"
I don't think volatile is necessarily wonderful in code _either_. So I
think the "atomic_read()" issue would be even better off if we just made
sure everybody behaves well an
Herbert Xu wrote:
On Thu, Aug 09, 2007 at 03:47:57AM -0400, Chris Snook wrote:
If they're not doing anything, sure. Plenty of loops actually do some sort
of real work while waiting for their halt condition, possibly even work
which is necessary for their halt condition to occur, and you defini
On Thu, Aug 09, 2007 at 03:47:57AM -0400, Chris Snook wrote:
>
> If they're not doing anything, sure. Plenty of loops actually do some sort
> of real work while waiting for their halt condition, possibly even work
> which is necessary for their halt condition to occur, and you definitely
> don'
On Thu, 09 Aug 2007 11:10:16 +0200
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> >
> > Why the *volatile-accesses-in-code* is acceptable, does C standard make it
> > clear?
>
> http://lwn.net/Articles/233482/
I have read this article before, but What Linus said only focusing on
the conclusion-- The
Jerry Jiang <[EMAIL PROTECTED]> wrote:
> On Wed, 8 Aug 2007 21:18:25 -0700 (PDT)
>> On Wed, 8 Aug 2007, Chris Snook wrote:
>> > Some architectures currently do not declare the contents of an atomic_t to
>> > be
>> > volatile. This causes confusion since atomic_read() might not actually
>> > read
On Thu, Aug 09, 2007 at 03:31:10AM -0400, Chris Snook wrote:
> Linus Torvalds wrote:
> > I'd be *much* happier with "atomic_read()" doing the "volatile" instead.
> > The fact is, volatile on data structures is a bug. It's a wart in the C
> > language. It shouldn't be used. Volatile accesses in *c
Herbert Xu wrote:
Chris Snook <[EMAIL PROTECTED]> wrote:
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
can b
Linus Torvalds wrote:
On Wed, 8 Aug 2007, Chris Snook wrote:
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
On Wed, 8 Aug 2007 21:18:25 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 8 Aug 2007, Chris Snook wrote:
> >
> > Some architectures currently do not declare the contents of an atomic_t to
> > be
> > volatile. This causes confusion since atomic_read() might not actually r
On Wed, 8 Aug 2007, Chris Snook wrote:
>
> Some architectures currently do not declare the contents of an atomic_t to be
> volatile. This causes confusion since atomic_read() might not actually read
> anything if an optimizing compiler re-uses a value stored in a register, which
> can break cod
On Wed, Aug 08, 2007 at 06:48:24PM -0700, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Thu, 09 Aug 2007 09:03:27 +0800
>
> > Such loops should always use something like cpu_relax() which comes
> > with a barrier.
>
> This is an excellent point.
>
> And it needs to be weighe
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 09 Aug 2007 09:03:27 +0800
> Such loops should always use something like cpu_relax() which comes
> with a barrier.
This is an excellent point.
And it needs to be weighed with the error prone'ness Andrew mentioned.
There probably is a middle ground
Chris Snook <[EMAIL PROTECTED]> wrote:
>
> Some architectures currently do not declare the contents of an atomic_t to be
> volatile. This causes confusion since atomic_read() might not actually read
> anything if an optimizing compiler re-uses a value stored in a register, which
> can break code
On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote:
> Jesper Juhl wrote:
> > On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote:
> >> From: Chris Snook <[EMAIL PROTECTED]>
> >>
> >> Some architectures currently do not declare the contents of an atomic_t to
> >> be
> >> volatile. This causes c
Lennert Buytenhek wrote:
On Wed, Aug 08, 2007 at 07:07:33PM -0400, Chris Snook wrote:
From: Chris Snook <[EMAIL PROTECTED]>
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an
Jesper Juhl wrote:
On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote:
From: Chris Snook <[EMAIL PROTECTED]>
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing com
On Wed, Aug 08, 2007 at 07:07:33PM -0400, Chris Snook wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Some architectures currently do not declare the contents of an atomic_t to be
> volatile. This causes confusion since atomic_read() might not actually read
> anything if an optimizing compile
On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Some architectures currently do not declare the contents of an atomic_t to be
> volatile. This causes confusion since atomic_read() might not actually read
> anything if an optimizing compiler re-uses
33 matches
Mail list logo
