Allow building Sage with GCC-4.7.x

[sagetrac-mariah]

Sage fails to build using GCC 4.7.0 on various systems, for different reasons.

• GFan: gfan 0.4plus [p1] fails to build with GCC 4.7.0 #12760
• Givaro: Givaro's (3.2.13.rc1) C++ headers don't conform to C++11 #12761
• LinBox: LinBox (1.1.6) fails to build with GCC 4.7.0, and lacks an spkg-check #12762
• PolyBoRi: Fix scoping / name look-up issue in PolyBoRi 0.8.0 and support flags from the environment #12750, Update PolyBoRi to release 0.8.1 #12655
• MPIR on ia64 (Itanium): MPIR doesn't compile with GCC-4.7.0 on ia64 #12765 (GCC bug) -- Upgrade MPIR to a more recent upstream release #11616 also provides an MPIR 2.4.0.p3 spkg working around this.
• MPFR on ia64 (Itanium): MPFR doesn't compile with GCC-4.7.0 on ia64 #12837 (same GCC bug) -- Note that MPFR is also a prerequisite for building the GCC spkg.
• GMP-ECM on ia64 (Itanium): Fixed by Work around GCC 4.7.0 bug on ia64 and improve the GMP-ECM spkg #12830 (same GCC bug)
• zn_poly on ia64 (Itanium): Fixed by Make zn_poly respect the CC environment variable, work around GCC 4.7.0 bug on ia64 (and clean up the spkg) #12433 (same GCC bug)
• FLINT, NTL and PARI (as well as the Sage library) all fail to build on ia64 due to the same bug,
• R fails to build on ia64 during byte-compiling; seems to be a different issue, but same work-around works. It also fails with -O3 during byte-compiling on Solaris SPARC and Linux x86_64; on the former -O2 works, on the latter somewhat surprisingly -O3 -flto. (Cf. comments below.)
• Two files (compat and linear) of PARI's test suite fail due to segfaults when compiling with -O3/-O2/-O1, at least on Linux x86 and x86_64.
• zlib on Solaris: Upgrade zlib to 1.2.6 #12800
• eclib on Solaris (See comments below; this is a Solaris header issue, fixed by a new spkg at Update eclib to latest upstream release #10993.)
• FLINTQS on Solaris: FLINTQS fails to build on Solaris (with GCC 4.7.x) #12855 (Also a subtle Solaris header issue.)
• Support GCC version "4.7": Support GCC version "4.7" in LinBox #13118.

gcc-4.7.1 spkg for testing purposes: #13150.

---

The ia64 bug is fixed in GCC 4.7.1, so we should apply the work-around only on GCC 4.7**.0** and only for packages which are prerequisites of GCC (since we don't plan to support Sage on ia64 with GCC 4.7.0, there is no point in work-arounds for some packages):

mpir-2.4.0.p6 (Jeroen Demeyer, 28 May 2012)

• Trac Allow building Sage with GCC-4.7.x #12751: Apply the ia64 workaround for gcc-4.7.0 only on
  gcc-4.7.0 and not on other gcc-4.7.x versions.

mpfr-3.1.0.p2 (Jeroen Demeyer, 28 May 2012)

• Trac Allow building Sage with GCC-4.7.x #12751: Apply the ia64 workaround for gcc-4.7.0 only on
  gcc-4.7.0 and not on other gcc-4.7.x versions.
• Remove pointless check for gmp.h.
• Rename MPFR_EXTRA_OPTS to MPFR_CONFIGURE for consistency with MPIR.

zn_poly-0.9.p9 (Jeroen Demeyer, 28 May 2012)

• Trac Allow building Sage with GCC-4.7.x #12751: remove the gcc-4.7.0 workaround for ia64 since this bug
  has been fixed in gcc-4.7.1 and we will not support building Sage
  with gcc-4.7.0 on Itanium.
• Don't override user-set CFLAGS and CXXFLAGS.

ecm-6.3.p8 (Jeroen Demeyer, 28 May 2012)

• Trac Allow building Sage with GCC-4.7.x #12751: remove the gcc-4.7.0 workaround for ia64 since this bug
  has been fixed in gcc-4.7.1 and we will not support building Sage
  with gcc-4.7.0 on Itanium.
• Remove unused variable SAGE_CONF_OPTS.
• Rename ECM_EXTRA_OPTS to ECM_CONFIGURE for consistency with MPIR.
• Don't override user-set CFLAGS.

---

Apply:

• attachment: 12751_allow_gcc_4_7.patch to SAGE_ROOT
• mpir: http://boxen.math.washington.edu/home/jdemeyer/spkg/mpir-2.4.0.p6.spkg
• mpfr: http://boxen.math.washington.edu/home/jdemeyer/spkg/mpfr-3.1.0.p2.spkg (also various misc changes)
• ecm: http://boxen.math.washington.edu/home/jdemeyer/spkg/ecm-6.3.p8.spkg (also various misc changes)
• zn_poly: http://boxen.math.washington.edu/home/jdemeyer/spkg/zn_poly-0.9.p9.spkg (also fixes user-supplied CFLAGS and CXXFLAGS being overridden)

CC: @jdemeyer @nexttime

Component: build

Keywords: GCC 4.7.0 C++11 -fpermissive compiler bugs sd40.5

Author: Jeroen Demeyer

Reviewer: Volker Braun

Merged: sage-5.2.beta1

Issue created by migration from https://trac.sagemath.org/ticket/12751

[nexttime]

Changed keywords from none to GCC 4.7.0 C++11

[nexttime]

comment:5

Also PARI 2.5.1's test suite fails due to segfaults in two test files, compat and linear (statically linked gp as well as the dynamically linked one).

SciPy's test suite fails to build due to an internal compiler error.

R now fails to build for me (when byte-compiling), interestingly only with less fancy GCC optimizations enabled. (It did build with LTO and Graphite loop optimization enabled).

This is all on Ubuntu 10.04.4 LTS x86_64.

[nexttime]

comment:7

Replying to @nexttime:

SciPy's test suite fails to build due to an internal compiler error.

Turns out that this isn't reproducible. Actually, in the first attempt (although with SAGE_CHECK=yes) the build failed, before the test suite got built or run.

I've then successfully rebuilt SciPy without SAGE_CHECK=yes, and now also again with it.

Nevertheless, SciPy's spkg-check (for whatever reason a Python script) is suboptimal, and spkg-install overwrites LDFLAGS. (It also unsets CFLAGS etc., but distutils take these from Python, so that's not as bad as it sounds, provided one doesn't want to rebuild [Python and] SciPy with different flags.)

[nexttime]

comment:8

Replying to @nexttime:

Also PARI 2.5.1's test suite fails due to segfaults in two test files, compat and linear (statically linked gp as well as the dynamically linked one).

FWIW, I get the same test errors in the build with GCC 4.7.0 with LTO and Graphite loop optimization enabled. Note that ptestlong passed for that build (with a couple of spkgs replaced, cf. sage-release thread for Sage 5.0.beta10).

[nexttime]

comment:9

Replying to @nexttime:

R now fails to build for me (when byte-compiling), interestingly only with less fancy GCC optimizations enabled. (It did build with LTO and Graphite loop optimization enabled).

This is really weird: R does build if I just in addition enable LTO... 8)

(My second Sage 5.0.beta10 build with GCC 4.7.0, without LTO and Graphite loop optimization, just used -march=native -O3 -g -fno-strict-aliasing.)

[nexttime]

comment:10

Replying to @nexttime:

Replying to @nexttime:

R now fails to build for me (when byte-compiling), interestingly only with less fancy GCC optimizations enabled. (It did build with LTO and Graphite loop optimization enabled).

This is really weird: R does build if I just in addition enable LTO... 8)

... and also passes its test suite with that.

[nexttime]

comment:12

Replying to @jdemeyer:

Btw., any timeline aimed at for the 5.0 release?

[jdemeyer]

comment:13

Replying to @nexttime:

Btw., any timeline aimed at for the 5.0 release?

No, but you should ask William Stein.

[nexttime]

comment:16

For the record: I've updated the LinBox spkg at #12762, now also adding an spkg-check script; the test suite wouldn't have built with GCC 4.7.0 (even with -fpermissive) [nor with 4.6.3], so I patched some upstream files in addition, and changed the "disable commentator" patch.

[nexttime]

Changed keywords from GCC 4.7.0 C++11 to GCC 4.7.0 C++11 -fpermissive compiler bugs

[jdemeyer]

comment:54

Replying to @vbraun:

There are still vestiges of ia64/gcc checking in the spkgs.

There should be in the MPIR and MPFR packages, because those are prerequisites for the Sage GCC spkg.

[jdemeyer]

comment:55

To clarify: we still want people with GCC-4.7.0 on ia64 to be able to build Sage, but only with the Sage-built GCC.

[nexttime]

comment:57

GCC 4.7.1 has been released on June 14th.

[nexttime]

comment:58

Replying to @vbraun:

There are still vestiges of ia64/gcc checking in the spkgs, I still believe that this should just once and for all be dealt with by the compiler wrapper instead of littering checks for $DYING_ARCH everywhere. But thats for another day ;)

Depends... The compiler wrapper (afaik) doesn't know what code or spkg it currently builds, and usually only few parts are affected (probably with different work-arounds). E.g. disabling optimization for the whole build is poor and may not even work.

It's probably more tedious to put [specific] work-arounds into a couple of spkgs, but IMHO also preserves some kind of modularity.

As a brute alternative, we could just blacklist (almost) all somehow non-functional compiler/OS combinations (most probably ignoring compiler options) in Sage's prerequisite check, but that's not very user- (nor developer-) friendly, and isn't "modular" either.

$DYING_ARCH does certainly have different values on different machines, or even depends on $USER... ;-)

[vbraun]

comment:59

Replying to @nexttime:

Depends... The compiler wrapper (afaik) doesn't know what code or spkg it currently builds, and usually only few parts are affected (probably with different work-arounds). E.g. disabling optimization for the whole build is poor and may not even work.

I disagree. Just because our testsuite didn't catch it doesn't mean that the code was compiled correctly. If the optimizer has a known bug then we must not use that particular optimization anywhere it if we want to trust the result.

[nexttime]

comment:60

Replying to @vbraun:

Replying to @nexttime:

Depends... The compiler wrapper (afaik) doesn't know what code or spkg it currently builds, and usually only few parts are affected (probably with different work-arounds). E.g. disabling optimization for the whole build is poor and may not even work.

I disagree. Just because our testsuite didn't catch it doesn't mean that the code was compiled correctly. If the optimizer has a known bug then we must not use that particular optimization anywhere it if we want to trust the result.

:-) Well, in the case I think you're referring to (ia64, "impossible reload"), the compiler bailed out, and it wasn't some "particular optimization", but the whole code generation (more precisely register allocation, in the presence of inline assemby) was broken, although only in some "corner cases".

You can almost never be sure all code will be compiled correctly [or otherwise raise an error] (under all circumstances), but testsuites are supposed to get at least some confidence. In this case certainly GCC's testsuite was insufficient, and/or the release hadn't been thoroughly tested [on ia64]. If instead we'd discovered -ffoo produced wrong code, we'd most probably used -fno-foo, globally. (But if the bug affected lots of code or situations, it certainly would have shown up earlier, upstream.)

In general, if you experience some function (or code, tool, whatever) gives wrong results on some inputs, you usually first try to narrow its domain, unless or until you can really fix it (and probably make sure it does work in all cases it was specified for). Dropping it completely until some "rare" issue is solved is not always an option (while documenting the issue is), or simply too inconvenient. Otherwise we'd never release any Sage version, since there are and always will be known "bugs" or limitations.

[vbraun]

comment:61

Its nice for the 2 remaining users (down from 3 now that skynet is down) of $DYING_ARCH, but I don't think its maintainable for Sage in the long run. Either we deprecate ancient compiler workarounds or the spkg-installs will fill up with crud that nobody remembers why it is there or what Itanium was.

I don't see a problem with disabling optimization on rare architectures where this can simply be fixed by updating the compiler from the point-oh release that you probably shouldn't have used anyways. And if your distribution backported a fix then you can still reenable optimizations.

[jdemeyer]

comment:62

Replying to @vbraun:

Its nice for the 2 remaining users (down from 3 now that skynet is down) of $DYING_ARCH, but I don't think its maintainable for Sage in the long run. Either we deprecate ancient compiler workarounds or the spkg-installs will fill up with crud that nobody remembers why it is there or what Itanium was.

The GCC spkg solves most of these issues.

[nexttime]

comment:63

Replying to @vbraun:

Its nice for the 2 remaining users (down from 3 now that skynet is down) of $DYING_ARCH, but I don't think its maintainable for Sage in the long run.

We can hardly officially support platforms we have no access to.

Is skynet intentionally down? Incidentally just tried to login...

Either we deprecate ancient compiler workarounds or the spkg-installs will fill up with crud that nobody remembers why it is there or what Itanium was.

Well, that's a matter of documentation (and wikipedia ;-) ).

We used to clean up "obsolete" work-arounds regularly, have our weird prerequisites check (besides checks in some spkgs' configure scripts), and we meanwhile have a GCC spkg anyway (although we still have to make sure bootstrapping works, as Jeroen mentioned).

IMHO the bigger problem is some distros (or OSs) shipping immature compilers by default (some not even providing fixes later). Always supporting the most recent GCC version on all skynet platforms may now be a requirement of the past; don't know.

[jdemeyer]

Merged: sage-5.2.beta1

[nexttime]

comment:65

There are still issues with GCC 4.7.0 (presumably any GCC 4.7.x) on Solaris, e.g. with Singular, similar to those with FLINTQS (#12855). (These are not related to compiler bugs!)

[nexttime]

comment:66

Replying to @nexttime:

There are still issues with GCC 4.7.0 (presumably any GCC 4.7.x) on Solaris, e.g. with Singular, similar to those with FLINTQS (#12855). (These are not related to compiler bugs!)

It seems only Singular (3-1-5) meanwhile needs to get fixed; this is #14295.