Re: [committed][trans-mem, aa64, arm, ppc, s390] Fixing PR68964

[Christophe Lyon <christophe dot lyon at linaro dot org>]

On 13 January 2016 at 18:17, Richard Henderson <rth@redhat.com> wrote:
> On 01/12/2016 08:53 AM, Richard Henderson wrote:
>>
>> The problem in this PR is that we never got around to flushing out the
>> vector
>> support for transactions for anything but x86.  My goal here is to make
>> this as
>> generic as possible, so that it should Just Work with existing vector
>> support
>> in the backend.
>>
>> In addition, if I encounter other unexpected register types, I will now
>> copy
>> them to memory and use memcpy, rather than crash.
>>
>> The one piece of this that requires a tiny bit of extra work is enabling
>> the
>> vector entry points in libitm.
>>
>> For x86, we make sure to build the files with SSE or AVX support enabled.
>> For
>> s390x, I do the same thing, enabling z13 support.  I suppose we might need
>> to
>> check for binutils support, but I'd rather do this only if necessary.
>>
>> For arm I'm less sure what to do, since I seem to recall that use of Neon
>> sets
>> a bit in the ELF header.  Which presumably means that the binary could no
>> longer be run without neon, even though the entry points wouldn't be used.
>>
>> For powerpc, I don't know how to select Altivec if VSX isn't already
>> enabled,
>> or indeed if that's the best thing to do.
>
>
> Based on feedback from dje, I now force -maltivec for the file; if the
> compilation flags already select power8 or the like, we continue to use vsx
> instructions in the file.
>
> I don't see an easy way to produce a universal build for arm32.  It may well
> be possible to do with extra effort.  If someone else would like to have a
> go,
> that's fine.  But given how gcc is built for the various distributions, I
> think it could be a waste of time.  Normally neon is going to be enabled or
> disabled at configure time, depending on the platform that is being
> targeted.
>
> Re-tested on x86_64, ppc64, s390x, and armv7l-linux-gnueabihf and committed.
>

Hi,

After this commit I can see this new failure:
gcc.dg/tm/memopt-5.c scan-tree-dump-times tmedge "ITM_LU[0-9]
\\(&lala.x\\[55\\]" 1

I'm not familiar with tm; I looked quickly at the dump, and saw:
  __builtin__ITM_LB (&lala.x[55], 4);
which is what is the most similar to what your are expecting to match.

>
> r~