This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch for PR libgomp/37938, IA64 specific.

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.  */
  expand_builtin_synchronize ();
  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
in these?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]