On 08/07/2017 02:42 AM, Alexander Monakov wrote:
> On Sat, 5 Aug 2017, Richard Sandiford wrote:
>> It would be simpler to test whether targetm.gen_mem_thread_fence
>> returns NULL.
>>
>> This feels a bit hacky though. Checking whether a generator produced no
>> instructions is usually the test for
On Sat, 5 Aug 2017, Richard Sandiford wrote:
> It would be simpler to test whether targetm.gen_mem_thread_fence
> returns NULL.
>
> This feels a bit hacky though. Checking whether a generator produced no
> instructions is usually the test for whether the generator FAILed, which
> should normally
Alexander Monakov writes:
> diff --git a/gcc/optabs.c b/gcc/optabs.c
> index a9900657a58..d568ca376fe 100644
> --- a/gcc/optabs.c
> +++ b/gcc/optabs.c
> @@ -6298,7 +6298,12 @@ void
> expand_mem_thread_fence (enum memmodel model)
> {
>if (targetm.have_mem_thread_fence ())
> -emit_insn (ta
As recently discussed in the previous thread for PR 80640, some targets have
sufficiently strong hardware memory ordering that implementation of C11 atomic
fences might not need machine barriers. However, a compiler memory barrier
nevertheless must be present, and at least two targets (x86, s390)
