Fix PyPy Compile Issues

[uxcn]

This fixes compile issues in dev-python/pypy and dev-python/pypy3. The builds are sensitive to cflags (see asmgcroot http://pypy.org/download.html).

These commits add support for stripping all cflags from an ebuild to flag-o-matic, and default to it without custom-cflags in pypy and pypy3 (live).

[gentoo-repo-qa-bot]

😞 The QA check for this pull request has found the following issues:

Issues persisted from underlying repository state:
https://qa-reports.gentoo.org/output/gentoo-ci/87101ea/output.html#dev-libs/efl
https://qa-reports.gentoo.org/output/gentoo-ci/87101ea/output.html#media-libs/elementary

[mgorny]

This is not going to fly. Stripping all flags is just wrong, and will cause fatal failures on some systems. strip-flags should be good enough, and I'm not going for that either. If you know some flags that cause issues, we could strip those.

[uxcn]

@mgorny Enumerating all the flag combinations that cause issues would be difficult, to say the least. My specific case was declaring the architecture for the compiler, but I'm not doing much else fancy. According to the PyPy developers, the build is sensitive in general with their default of asmgcroot on linux.

In my case, the existing strip-flags doesn't strip the architecture, which is the cause of the compile failures. The best way to get a stable build seems to be relying on pypy's defaults, but maybe there's another solution? Note, I added a custom-cflags use to the builds to support custom compile and link options (similar to a few other builds).

What would be an example of a system where stripping all flags would be fatal?

[mgorny]

That's more than weird. -march really shouldn't be causing any failures unless they are doing some absurd assumptions.

[mgorny]

(or compiler is broken)

[uxcn]

@mgorny Per PyPy developers, asmgcroot, as opposed to shadowstack, is extremely sensitive to the compiler and architecture.

Is there any mechanism to determine a base instruction set in portage (e.g. ivybridge -> x86->64)?

[mgorny]

Not exactly. However, there's replace-cpu-flags that could be helpful here, at least for common known-wrong CPUs. Furthermore, -mno-* flags may be even better — i.e. disabling instruction sets that cause the emitted prologue to be changed.

But to be honest, reading the upstream answer there, I would consider switching to shadowstack by default, and possibly dropping non-shadowstack at some point, if upstream doesn't do that first.

[mgorny]

Hmm, if you could work on this a bit more, could you try figuring out which -march are known to cause this and which are not? Possibly by looking at existing reports. If we can determine the 'lowest' CPU series causing the issue, it'd be relatively easy to compare enabled -m flags.

[uxcn]

Using shadowstack instead of asmgcroot compiles without issue (including LTO for pypy3). However, there's isn't any formal indication when PyPy will eliminate asmgcroot.

I would argue that normalizing -march and -mtune to x86(64) should be sufficient since it's known good. That should solve the issue for anyone building the package. Putting more specific architectures behind custom-cflags also lets people experiment.

I can try to implement this, but it's a bit more involved.

[mgorny]

Hmm, just to be clear, are you getting this error with -march=ivybridge or was that purely an example? And which gcc version? Because from what I can see in gcc sources, it's equivalent to -march=core-avx-i which I'm using without any problems…

[uxcn]

I wouldn't be too surprised core-avx-i was an alias for ivybridge. The specific compile issue I see is with -O3 -march=ivybridge -mtune=ivybridge and GCC 4.9.3. However, there are a number of other bug reports regarding the same issue, which was why I tried to submit a patch.

My hope was that it would cut down on build issues people might have, bug reports, and hopefully make things a tiny bit simpler for others. I've noticed a few other projects have taken a similar tack (e.g. chromium, wine, x264, etc...).

The reason for the original approach was to preserve the standard linux default for PyPy (asmgcroot), but still provide support for custom-cflags. Since shadowstack seems to be a bit more robust to compiler optimization it might make sense to make custom-cflags implied by shadowstack, but it seems like a large amount of effort to keep track of safe compiler optimizations. Worse, I think it makes for confusing semantics when building/installing.

[mgorny]

Well, one of the ideas behind PyPy is that it's supposed to be fast. Forcing optimizations down to pure common denominator (which is really bad considering early AMD64 vs Intel) opposes that. And as you can see, most of those bug reports resulted in upstream fixes. I'm going to try to experiment a bit on a strong server.

[mgorny]

I'm afraid I can't test this much since PyPy relies on run checks, and my server can't run ivybridge executables.

[uxcn]

If PyPy has a benchmark suite, it may help to compare between common (x86-64) and architecture tuned (e.g. broadwell) with both asmgcroot and shadowstack, particularly 4+. I've been able to build shadowstack with LTO both with gcc and clang, notably reducing binary size dramatically, which may also be worth comparison.

Note, LTO has also been successfully used with firefox giving non-trivial results and correct compilation so far. The JIT isn't explicitly benchmarked, although the page benchmarks are heavily javascript dependent which may or may not be relevant. Surprisingly, it currently fails to compile w/ Gentoo.

[mgorny]

LTO is only relevant to people who have enough RAM ;-P.

[uxcn]

The footprint for bigger stuff like libreoffice and firefox used to be ginormous. It's come down a lot over the last few versions of gcc and clang, along with better performance, but LTO is definitely difficult to scale. Linking PyPy took something like a half hour with clang. It's a bit faster with gcc since it uses partitions, but the results aren't completely deterministic.

[mgorny]

I'm going to close this since this is not really a solution and it does not follow the procedure for eclass changes. I think we should focus on targeting specific issues with specific fixes. If you have some known-needed replace-cpu-flags, please submit them.

[uxcn]

I would hazard a guess there are going to be more build issues going forward without normalizing cflags, especially with skylake and kabylake around the corner. It may at least be worth posting info on using shadowstack instead of asmgcroot.