Re: [PATCH][libstc++v3]Add new dg-require-thread-fence directive.

[Jonathan Wakely <jwakely at redhat dot com>]

On 21/04/15 15:29 +0100, Renlin Li wrote:
> Hi all,
>
> This patch defines a new dg-require-thread-fence directive. And three 
> test cases are updated to use it.
>
> The new directive are used to check whether the target support thread 
> fence either by the target back-end or external library function call. 
> A thread fence is required to expand atomic load/store.
>
> There is a case that a call to some external __sync_synchronize will 
> be emitted, and it's not implemented. You will get linking errors like 
> this: undefined reference to `__sync_synchronize`. Test cases which 
> are gated by this directive will be skipped if no thread fence is 
> available. For example the three test cases updated here. They fail on 
> arm-none-eabi target where __sync_synchronize() isn't implemented and 
> target cpu has no memory_barrier.
>
> ___sync_synchronize () is used to check whether thread-fence is 
> available. In GCC sync_synchronize is expanded as 
> expand_mem_thread_fence (MEMMODEL_SEQ_CST).

I don't like making the directive depend directly on the legacy
__sync_synchronize function, because that function is not required on
most targets, AFAICT it's only needed for ARM and MIPS.

Could you make the directive check
__atomic_thread_fence(__ATOMIC_SEQ_CST) instead? I think that will
still expand to __sync_synchronize() for ARM, so should still test the
same thing, but that way we aren't adding a dependency on
__sync_synchronize for all targets.