On 13 January 2016 at 18:17, Richard Henderson <r...@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~
