lkml.org 
[lkml]   [2010]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock
    On 07/14/2010 12:40 PM, H.J. Lu wrote:
    > On Wed, Jul 14, 2010 at 12:36 PM, H. Peter Anvin <hpa@zytor.com> wrote:
    >
    >> On 07/14/2010 12:32 PM, H.J. Lu wrote:
    >>
    >>> On Wed, Jul 14, 2010 at 12:00 PM, H. Peter Anvin <hpa@zytor.com> wrote:
    >>>
    >>>> On 07/14/2010 11:18 AM, H.J. Lu wrote:
    >>>>
    >>>>> There are some discussions on:
    >>>>>
    >>>>> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02001.html
    >>>>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00001.html
    >>>>>
    >>>>> Are they related?
    >>>>>
    >>>>>
    >>>> Not directly as far as I can tell.
    >>>>
    >>>> The issue is if gcc can ever reorder, duplicate or elide a volatile
    >>>> operation (either asm volatile or a volatile-annotated memory
    >>>> reference.) In my (and Linus') opinion, this would be an incredibly
    >>>> serious bug.
    >>>>
    >>> Is there a gcc bug for this?
    >>>
    >>>
    >> Are you asking for a bug report against the documentation? We're not
    >> sure what the semantics intended by the gcc team to be, which I guess is
    >> a documentation bug.
    >>
    >>
    > Documentation bug is also a bug :-).
    >

    The question is "what are the real ordering semantics of asm volatile"?
    What ordering is enforced between other asm volatiles? What ordering is
    enforced between asm volatiles and regular memory accesses? asm volatile
    and other code?

    The documentation discusses this to some extent, but mostly says "there
    are no ordering guarantees". Older versions of gcc - 2.95, for example
    - are more explicit, saying that "asm volatiles" won't be moved out of
    their basic block (I think that's how I parse it, anyway).

    Linux relies on "asm volatile" being ordered at least with respect to
    other asm volatiles. Is this reasonable now? Will gcc break this at
    some point in the future? If we can't rely on "asm volatile" ordering
    semantics, what other mechanism can we use (for example, to order clts
    with respect to FPU-using code)?

    Thanks,
    J


    \
     
     \ /
      Last update: 2010-07-14 23:13    [W:3.291 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site