On Fri, 22 May 2015, Andreas Krebbel wrote: > Hi, > > in order to get the IBM z13 support into present distros the Linux > distributors asked me to get this > stuff upstream into the older GCC branches first. This would ease the whole > backporting efforts, > interactions with other patches and would make sure that everybody uses the > same code level. > > This would affect at least the GCC 4.8 and 5 branches but for continuity > reasons it probably also > should go into 4.9 then. > > The patchset requires only very minor common code changes and therefore > imposes only a low risk for > other platforms: > > recog: Increased max number of alternatives - v2 > https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02059.html
On branches you'd have to use unsigned HOST_WIDE_INT (where that might be 32bits on some hosts!). We still support hosts without uint64_t here. So this might already be a no-go. > optabs: Fix vec_perm -> V16QI middle end lowering. > https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02058.html > > There is definitely some risk for S/390 but this again should be > relatively low when compiling for CPU levels prio to z13. > > For the z13 support itself I've added a bunch of testcases but I've also > run checks with about 10000 automatically generated testcases not part > of the patchset. > > We also ran the ABI comparison testsuite to compare the GCC and LLVM > implementations regarding vector data types. > > Is it ok to apply the patchset to GCC 4.8, 4.9, and 5 branches as well? I'm somewhat missing the point of backporting z13 support. ppc64le enablement was a different story (IBM basically saying ppc64-linux is dead), but surely all z13 machines can run non-z13 code just fine. s390x-linux-gnu is a secondary platform so I don't think we'd want to destabilize it (esp. on the 4.8 branch where I expect only one more release around the end of June with no chance to fix things up). So that's a "no" from me basically. But I'm willing to be convinced otherwise (not having looked into the z13 backend patches at all). CCing that other release manager we have as well. Thanks, Richard. -- Richard Biener <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)