This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2, middle-end]: Introduce memory_blockage named insn pattern
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Uros Bizjak <ubizjak at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 14 Oct 2017 14:28:00 -0400
- Subject: Re: [PATCH v2, middle-end]: Introduce memory_blockage named insn pattern
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnyneV9tZhqk0-0pw338qT3Wa6eR1f2R=u7H-m_4PHpJMqg@mail.gmail.com> <CAFULd4bqBi_oPC=3tXDxJfbDNJ4cb7N-y_4eeFoLamfee=8CpA@mail.gmail.com>
On Sat, Oct 14, 2017 at 1:29 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Sat, Oct 14, 2017 at 5:44 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> This patch has broken bootstrap on AIX and possibly powerpc64-linux.
>> Was this patch tested on any architecture other than x86?
>
> No.
>
>> /nasfarm/edelsohn/src/src/libgcc/emutls.c: In function '__emutls_get_address':
>> /nasfarm/edelsohn/src/src/libgcc/emutls.c:139:11: internal compiler
>> error: in invalid_void, at config/rs6000/rs6000.md:10804
>> pointer offset = __atomic_load_n (&obj->loc.offset, __ATOMIC_ACQUIRE);
>> ^~~~~~
>
> Basically, the patch does only:
>
> +expand_memory_blockage (void)
> +{
> + if (targetm.have_memory_blockage)
> + emit_insn (targetm.gen_memory_blockage ());
> + else
> + expand_asm_memory_blockage ();
> +}
>
> So, if the target doesn't declare memory_blockage pattern, as is the
> case with rs6000, I really fail to see what could go wrong here.
Thanks for finding and fixing the targetm.have_memory_blockage typo.
- David