This is the mail archive of the
mailing list for the GCC project.
Re: Patch for PR libgomp/37938, IA64 specific.
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Steve Ellcey <sje at cup dot hp dot com>, Richard Henderson <rth at redhat dot com>, hjl at gnu dot org
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 4 Nov 2008 18:17:33 +0100
- Subject: Re: Patch for PR libgomp/37938, IA64 specific.
- References: <200811041650.mA4GoSX10081@lucas.cup.hp.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Nov 04, 2008 at 08:50:28AM -0800, Steve Ellcey wrote:
> Some libgomp tests were failing on IA64 Linux (but not HP-UX), the
> problem was that Linux uses the sync_lock_test_and_set instruction and
> this did not have a memory barrier in it to make sure that loads and
> stores were completed before the sync_lock_test_and_set instruction was
> executed. This patch changes sync_lock_test_and_set to a define_expand
> that has a memory barrier followed by the original xchg instruction (now
> renamed to sync_lock_test_and_set_xchg).
I think having a memory barrier there matches our documentation:
"In most cases, these builtins are considered a "full barrier". That
is, no memory operand will be moved across the operation, either
forward or backward. Further, instructions will be issued as necessary
to prevent the processor from speculating loads across the operation
and from queuing stores after the operation."
and what other ports do as well. Shouldn't
sync_lock_release<mode> get the same treatment on ia64 though?
E.g. ppc has gen_lwsync in sync_lock_release and the generic implementation
/* Otherwise we can implement this operation by emitting a barrier
followed by a store of zero. */
emit_move_insn (mem, val);
(wonder why the generic one isn't sufficient for ia64).
When we are talking about __sync* builtins, H.J., does icc imply a barrier