[lkml]   [2007]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/24] make atomic_read() behave consistently across all architectures

    On Sat, 18 Aug 2007, Segher Boessenkool wrote:

    > > > > > atomic_dec() writes
    > > > > > to memory, so it _does_ have "volatile semantics", implicitly, as
    > > > > > long as the compiler cannot optimise the atomic variable away
    > > > > > completely -- any store counts as a side effect.
    > > > >
    > > > > I don't think an atomic_dec() implemented as an inline "asm volatile"
    > > > > or one that uses a "forget" macro would have the same re-ordering
    > > > > guarantees as an atomic_dec() that uses a volatile access cast.
    > > >
    > > > The "asm volatile" implementation does have exactly the same
    > > > reordering guarantees as the "volatile cast" thing,
    > >
    > > I don't think so.
    > "asm volatile" creates a side effect.


    > Side effects aren't
    > allowed to be reordered wrt sequence points.


    > This is exactly
    > the same reason as why "volatile accesses" cannot be reordered.

    No, the code in that sub-thread I earlier pointed you at *WAS* written
    such that there was a sequence point after all the uses of that volatile
    access cast macro, and _therefore_ we were safe from re-ordering
    (behaviour guaranteed by the C standard).

    But you seem to be missing the simple and basic fact that:

    (something_that_has_side_effects || statement)
    != something_that_is_a_sequence_point

    Now, one cannot fantasize that "volatile asms" are also sequence points.
    In fact such an argument would be sadly mistaken, because "sequence
    points" are defined by the C standard and it'd be horribly wrong to
    even _try_ claiming that the C standard knows about "volatile asms".

    > > > if that is
    > > > implemented by GCC in the "obvious" way. Even a "plain" asm()
    > > > will do the same.
    > >
    > > Read the relevant GCC documentation.
    > I did, yes.

    No, you didn't read:

    Read the bit about the need for artificial dependencies, and the example
    given there:

    asm volatile("mtfsf 255,%0" : : "f" (fpenv));
    sum = x + y;

    The docs explicitly say the addition can be moved before the "volatile
    asm". Hopefully, as you know, (x + y) is an C "expression" and hence
    a "sequence point" as defined by the standard. So the "volatile asm"
    should've happened before it, right? Wrong.

    I know there is also stuff written about "side-effects" there which
    _could_ give the same semantic w.r.t. sequence points as the volatile
    access casts, but hey, it's GCC's own documentation, you obviously can't
    find fault with _me_ if there's wrong stuff written in there. Say that
    to GCC ...

    See, "volatile" C keyword, for all it's ill-definition and dodgy
    semantics, is still at least given somewhat of a treatment in the C
    standard (whose quality is ... ummm, sadly not always good and clear,
    but unsurprisingly, still about 5,482 orders-of-magnitude times
    better than GCC docs). Semantics of "volatile" as applies to inline
    asm, OTOH? You're completely relying on the compiler for that ...

    > > [ of course, if the (latest) GCC documentation is *yet again*
    > > wrong, then alright, not much I can do about it, is there. ]
    > There was (and is) nothing wrong about the "+m" documentation, if
    > that is what you are talking about. It could be extended now, to
    > allow "+m" -- but that takes more than just "fixing" the documentation.

    No, there was (and is) _everything_ wrong about the "+" documentation as
    applies to memory-constrained operands. I don't give a whit if it's
    some workaround in their gimplifier, or the other, that makes it possible
    to use "+m" (like the current kernel code does). The docs suggest
    otherwise, so there's obviously a clear disconnect between the docs and
    actual GCC behaviour.

    [ You seem to often take issue with _amazingly_ petty and pedantic things,
    by the way :-) ]
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-18 03:47    [W:0.029 / U:0.336 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site