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

[Richard Henderson <rth at redhat dot com>]

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.


r~

Attachment: d-68964-2
Description: Text document