From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6339 invoked by alias); 21 Nov 2008 23:22:08 -0000 Received: (qmail 26152 invoked by uid 48); 21 Nov 2008 23:20:47 -0000 Date: Fri, 21 Nov 2008 23:22:00 -0000 Message-ID: <20081121232047.26151.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/36793] x86-64 does not get __sync_synchronize right In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "samuel dot thibault at ens-lyon dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-11/txt/msg01845.txt.bz2 ------- Comment #5 from samuel dot thibault at ens-lyon dot org 2008-11-21 23:20 ------- We do already know which x86 memory barrier instruction we need, that's not the problem, no need to give us pointers to documentations. The problem is that we'd like to not use explicit x86 instructions but rather rely on the "portability" of gcc's __sync_synchronize. If your answer is "sync_foobar is not specified for baz", all these __sync_foobar become useless, since the user can't assume what their are supposed to achieve. From what the documentation says, I had assumed that gcc would implement for other archs what Intel documents for ia64, but it happens not to be the case at least for sync_synchronize. So in short, if that's your answer to the bug, then I'll have to tell people _not_ to use gcc's __sync_* at all except on ia64, since that would be the only arch on which we would have any semantic guarantee... (and then the documentation needs to be fixed). Of course, that's not an option I'd like, and actually I believe there may be SMP bugs in libgc & such that use it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793