Add a gcc package

[jdemeyer]

The aim is to add a GCC package (GNU compiler collection) to Sage with compilers for C, C++ and Fortran. We don't always build it, we would install it by default only on systems where this is needed. This would replace the fortran package.

spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/gcc-4.6.3.spkg

Apply:

1. attachment: 12369_gcc_root.patch and attachment: 12369_gcc_root_part2.patch to the SAGE_ROOT repository.
2. attachment: 12369_scripts_hgignore.patch to the SCRIPTS repository.
3. attachment: 12369_doc.patch to the Sage library.

See also:

1. 12782: When building GCC, build MPIR without the C++ interface (superseded by #11616).

Depends on #12479 Depends on #12602 Depends on #12608 Depends on #12609 Depends on #12647 Depends on #10492 Depends on #12367 Depends on #12368 Depends on #12405 Depends on #12570 Depends on #12574 Depends on #12423 Depends on #12425 Depends on #12456 Depends on #12363 Depends on #12223 Depends on #12515 Depends on #12519 Depends on #12548 Depends on #12562 Depends on #12629 Depends on #12638 Depends on #12714 Depends on #12647 Depends on #12739 Depends on #12112 Depends on #12631

CC: @vbraun

Component: packages: standard

Author: Jeroen Demeyer

Reviewer: Simon King

Merged: sage-5.0.beta13

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

[jhpalmieri]

comment:95

Well, the old gcc works fine on OS X PPC, so we can just keep using that, right?

[kcrisman]

comment:96

Yeah, I really don't see the need to build gcc on older Mac platforms at all. This unnecessarily complicates things. I understand if this is necessary for Lion, but might as well stick with what works for the others.

[jdemeyer]

comment:97

Replying to @kcrisman:

Yeah, I really don't see the need to build gcc on older Mac platforms at all. This unnecessarily complicates things. I understand if this is necessary for Lion, but might as well stick with what works for the others.

We need to build GCC to have Fortran. Or we have to ship Fortran sources and binaries which makes no sense at all.

You could argue that we shouldn't use the gcc that we built. But I would expect gcc-4.6.3 to be better than Apple's gcc-4.0.1 (even though it contains bugs).

[jdemeyer]

Changed dependencies from #10492, #12367, #12368, #12405, #12570, #12574, #12423, #12425, #12456, #12363, #12223, #12515, #12519, #12548, #12562, #12629, #12011 to #10492, #12367, #12368, #12405, #12570, #12574, #12423, #12425, #12456, #12363, #12223, #12515, #12519, #12548, #12562, #12629, #12011, #12638

[kcrisman]

comment:99

Replying to @jdemeyer:

Replying to @kcrisman:

Yeah, I really don't see the need to build gcc on older Mac platforms at all. This unnecessarily complicates things. I understand if this is necessary for Lion, but might as well stick with what works for the others.

We need to build GCC to have Fortran. Or we have to ship Fortran sources and binaries which makes no sense at all.

Oh, I see - I forgot about this replacing the Fortran.

You could argue that we shouldn't use the gcc that we built. But I would expect gcc-4.6.3 to be better than Apple's gcc-4.0.1 (even though it contains bugs).

Well, but if it won't compile Pari, then maybe we should just stick with that. Why not just use the old Apple-shipped gcc for 10.4 and 10.5 or something? That seems very reasonable. And cuts down on build time for already old slow systems.

[jdemeyer]

comment:100

Replying to @kcrisman:

Well, but if it won't compile Pari, then maybe we should just stick with that.

In the mean time, I posted a work-around for PARI at #12638.

And cuts down on build time for already old slow systems.

Sure, it will, but I don't think "build time" really matters.

I much prefer run-time performance than build-time performance (if you really want the latter, compile everything with -O0). And one would expect run-time performance to be better with more recent GCC versions (although it will change by at most a few percent).

[jdemeyer]

comment:101

Another argument pro GCC-4.6.3 is that fixing things to work with newer GCC versions usually improves portability in general. For example, I don't think the miscompilation of PARI is specific to OS X PPC. It would probably fail on Linux PPC too.

[jdemeyer]

comment:102

I believe this is ready for review now. I don't know of any regressions, in the following sense: for every system on which vanilla sage-5.0.beta7 works, also sage-5.0.beta7-gccdeps and sage-5.0.beta7-gcc work.

It even builds and passes all tests on OS X 10.7, but there is still a serious issue with ATLAS (#12011, causing a failure in the cvxopt test suite). But I don't believe that should prevent a review of this ticket, as it's unrelated to GCC.

[jdemeyer]

Description changed:

--- 
+++ 
@@ -10,3 +10,8 @@
 **Testing releases**:
 1. GCC-4.6.3: [http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gcc/](http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gcc/)
 2. Dependencies only: [http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gccdeps/](http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gccdeps/): this contains all *dependencies* of this ticket but not this ticket itself, it still includes the old Fortran spkg.
+
+Neither of these releases contain a fixed ATLAS (#12011), as that's work in progress.
+
+For systems other than OS X, installing the "gccdeps" distribution is equivalent to installing the "gcc" distribution with `SAGE_INSTALL_GCC=no`.  On OS X, the "gcc" distribution normally will not build with `SAGE_INSTALL_GCC=no` because Fortran is missing.
+

[kcrisman]

comment:103

Well, but if it won't compile Pari, then maybe we should just stick with that.

In the mean time, I posted a work-around for PARI at #12638.

And cuts down on build time for already old slow systems.

Sure, it will, but I don't think "build time" really matters.

Well, all fair enough. Just want to make sure I'm asking the questions, even if they're dumb :)

[jdemeyer]

Description changed:

--- 
+++ 
@@ -11,7 +11,7 @@
 1. GCC-4.6.3: [http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gcc/](http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gcc/)
 2. Dependencies only: [http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gccdeps/](http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gccdeps/): this contains all *dependencies* of this ticket but not this ticket itself, it still includes the old Fortran spkg.

-Neither of these releases contain a fixed ATLAS (#12011), as that's work in progress.
+Neither of these releases contain a fix for cvxopt on OS X 10.7 (#12011), as that's work in progress.

 For systems other than OS X, installing the "gccdeps" distribution is equivalent to installing the "gcc" distribution with `SAGE_INSTALL_GCC=no`.  On OS X, the "gcc" distribution normally will not build with `SAGE_INSTALL_GCC=no` because Fortran is missing.

[jdemeyer]

Changed dependencies from #10492, #12367, #12368, #12405, #12570, #12574, #12423, #12425, #12456, #12363, #12223, #12515, #12519, #12548, #12562, #12629, #12011, #12638 to #12479, #12602, #12608, #12609, #10492, #12367, #12368, #12405, #12570, #12574, #12423, #12425, #12456, #12363, #12223, #12515, #12519, #12548, #12562, #12629, #12011, #12638

[jdemeyer]

Description changed:

--- 
+++ 
@@ -1,4 +1,4 @@
-The aim is to add a gcc package to Sage.  We probably don't want to always build it, we would install it by default only on systems where this is needed.  This would replace the fortran package.
+The aim is to add a GCC package (GNU compiler collection) to Sage with compilers for C, C++ and Fortran.  We don't always build it, we would install it by default only on systems where this is needed.  This would replace the fortran package.

 **spkg**: [http://boxen.math.washington.edu/home/jdemeyer/spkg/gcc-4.6.3.spkg](http://boxen.math.washington.edu/home/jdemeyer/spkg/gcc-4.6.3.spkg)

[jdemeyer]

Description changed:

--- 
+++ 
@@ -11,7 +11,5 @@
 1. GCC-4.6.3: [http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gcc/](http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gcc/)
 2. Dependencies only: [http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gccdeps/](http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gccdeps/): this contains all *dependencies* of this ticket but not this ticket itself, it still includes the old Fortran spkg.

-Neither of these releases contain a fix for cvxopt on OS X 10.7 (#12011), as that's work in progress.
-
 For systems other than OS X, installing the "gccdeps" distribution is equivalent to installing the "gcc" distribution with `SAGE_INSTALL_GCC=no`.  On OS X, the "gcc" distribution normally will not build with `SAGE_INSTALL_GCC=no` because Fortran is missing.

[jdemeyer]

Changed dependencies from #12479, #12602, #12608, #12609, #10492, #12367, #12368, #12405, #12570, #12574, #12423, #12425, #12456, #12363, #12223, #12515, #12519, #12548, #12562, #12629, #12011, #12638 to #12479, #12602, #12608, #12609, #10492, #12367, #12368, #12405, #12570, #12574, #12423, #12425, #12456, #12363, #12223, #12515, #12519, #12548, #12562, #12629, #12638

[simon-king-jena]

comment:108

Building the gcc spkg really takes an awful lot of time.

One question: If I want to rebuild Sage with the compiler built by the spkg, perhaps with additional optimizations (provided that the gcc-spkg is able to pick up my system-wide CLooG or I manage to make a CLooG spkg), how could I do so?

Of course, sage -ba would recompile all Cython code in the Sage library, but it would not re-install the spkgs. Is there an easy way to install all standard packages from scratch? I am not talking about an automatic re-installation of the optional packages.

In particular, would it work to remove all entries in SAGE_ROOT/spkg/installed that correspond to standard packages, and do make again? Or perhaps better exempt the sage* spkgs from re-installation, since my Sage library is patched?

[jdemeyer]

comment:109

Replying to @simon-king-jena:

Of course, sage -ba would recompile all Cython code in the Sage library, but it would not re-install the spkgs. Is there an easy way to install all standard packages from scratch? I am not talking about an automatic re-installation of the optional packages.

In particular, would it work to remove all entries in SAGE_ROOT/spkg/installed that correspond to standard packages, and do make again?

Yes, that should work.

Or perhaps better exempt the sage* spkgs from re-installation, since my Sage library is patched?

I honestly have no idea what would happen if you re-install the Sage library over a patched version.

[jdemeyer]

Changed dependencies from #12479, #12602, #12608, #12609, #10492, #12367, #12368, #12405, #12570, #12574, #12423, #12425, #12456, #12363, #12223, #12515, #12519, #12548, #12562, #12629, #12638 to #12479, #12602, #12608, #12609, #12647, #10492, #12367, #12368, #12405, #12570, #12574, #12423, #12425, #12456, #12363, #12223, #12515, #12519, #12548, #12562, #12629, #12638

[simon-king-jena]

comment:111

Hooray, the spkg did install, and it did early enough that I will catch the next bus. But it took long enough that I missed two buses...

On sage-devel, we discussed whether the gcc package would pick up a system wide installation of CLooG. In the install log of the spkg, I do find lines such as

gcc -c   -O0 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I/home/simon/SAGE/sage-5.0.beta7/local/include -I/home/simon/SAGE/sage-5.0.beta7/local/include -I/home/simon/SAGE/sage-5.0.beta7/local/include  -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/bid -I../libdecnumber    ../../src/gcc/graphite-cloog-util.c -o graphite-cloog-util.o

Does that mean that CLooG/graphite will work?

Here is the log.

[simon-king-jena]

comment:112

On sage-devel, Jeroen said that I should look in the configure part of the log. There, I can not find CLooG mentioned. Am I right? If that is the case, then I would try to add an optional CLooG spkg, which could then use the gmp-5.0.4 spkg.

[jdemeyer]

comment:113

Replying to @simon-king-jena:

Does that mean that CLooG/graphite will work?

No, because it can't find PPL:

checking for version 0.11 (revision 0 or later) of PPL... no

If PPL isn't found, then GCC doesn't even bother looking for CLooG.

I will change the GCC spkg such that it looks for PPL in $SAGE_LOCAL.

[jdemeyer]

comment:114

Hmm, the problem is not with GCC, but with the PPL in Sage. It seems Sage-PPL doesn't install ppl_c.h which is needed for GCC. I don't know more about this.

[simon-king-jena]

comment:115

Replying to @jdemeyer:

Hmm, the problem is not with GCC, but with the PPL in Sage. It seems Sage-PPL doesn't install ppl_c.h which is needed for GCC. I don't know more about this.

:((

Anyway. I thought it would not hurt to create an optional CLooG spkg: See #12666.

The upgraded optional gmp spkg is at #12661.

[simon-king-jena]

comment:116

Replying to @jdemeyer:

Hmm, the problem is not with GCC, but with the PPL in Sage. It seems Sage-PPL doesn't install ppl_c.h which is needed for GCC. I don't know more about this.

There is ppl.hh provided by the PPL spkg. But I can not find ppl_c.h in the spkg's sources, and also I can not find any mention of ppl_c.h in the spkg's install log.

So, where could ppl_c.h come from?

[vbraun]

comment:117

The PPL spkg does not install the C interface since we only use the native C++ interface in Sage. It would be easy to also build the C interface but I don't quite understand where we are heading here. Nobody is going to have a usable CLooG/Graphite laying around without a working GCC build. On Linux its easier to install a fully working GCC than just CLooG, I daresay. And a quick grep through the install.log suggests that nothing is being built with -floop* options.

[jdemeyer]

comment:118

Replying to @vbraun:

I don't quite understand where we are heading here.

I guess Simon's idea is to have an optional CLooG spkg in Sage, such that people could build Sage's GCC with PPL+CLooG.

[simon-king-jena]

comment:119

Replying to @jdemeyer:

Replying to @vbraun:

I don't quite understand where we are heading here.

I guess Simon's idea is to have an optional CLooG spkg in Sage, such that people could build Sage's GCC with PPL+CLooG.

Yes. And of course -floop* options aren't used - yet. But according to some statement on sage-devel, sometimes 30% more speed is possible with such options. So, I am curious whether I'd obtain a noticeable speed difference when I add those kind of options to CFLAGS/CXXFLAGS and do sage -ba.

[simon-king-jena]

comment:120

Replying to @vbraun:

The PPL spkg does not install the C interface since we only use the native C++ interface in Sage.

Thank you! I changed the ppl spkg's install script accordingly, and now I have ppl_c.h in SAGE_LOCAL/include.

[simon-king-jena]

comment:121

Replying to @simon-king-jena:

Replying to @vbraun:

The PPL spkg does not install the C interface since we only use the native C++ interface in Sage.

Thank you! I changed the ppl spkg's install script accordingly, and now I have ppl_c.h in SAGE_LOCAL/include.

It didn't help, I'm afraid.

I have ppl_c.h, I have GMP, and I have CLooG. However, when building the GCC spkg again, the log contains the line

checking for installed CLooG PPL Legacy... no

Any idea what is missing? I am afraid that I was not able to copy the log to sage.math, but I'll try again later.

[simon-king-jena]

comment:122

Is it perhaps needed to build CLooG again after building PPL with C interface? At least this is what I am trying now.

[simon-king-jena]

comment:123

Replying to @simon-king-jena:

Is it perhaps needed to build CLooG again after building PPL with C interface?

No, it doesn't work. It still says there is no CLooG PPL Legacy.

[simon-king-jena]

comment:124

Could it be that there is an important difference between cloog and cloog-ppl?

Google pointed me to cloog-ppl, but I could not find sources (although it seems to be a different package than cloog).

[simon-king-jena]

comment:125

I found cloog-ppl sources. But there's the next problem. It says:

...
Can't find PolyLib.
checking for Parma Polyhedral Library (PPL)... not using PPL
...
In file included from source/block.c:41:0:
source/../include/cloog/cloog.h:47:30: schwerwiegender Fehler: polylib/missing.h: Datei oder Verzeichnis nicht gefunden
Kompilierung beendet.

PolyLib is not listed as a dependency, but ppl is.

So, why is it (still!) claimed that we are not using PPL, even though we have ppl_c.h and ppl.hh???

I apologize for the fact that it is slightly off topic - but I'd still like to learn how to build your gcc spkg with -floop* support.

[simon-king-jena]

comment:126

Replying to @simon-king-jena:

Can't find PolyLib. checking for Parma Polyhedral Library (PPL)... not using PPL

Hooray! in my cloog_ppl spkg (not submitted yet) I had simply forgotten to add --with-ppl to the configuration. And now, your gcc package says

checking for installed CLooG PPL Legacy... PPL Legacy
checking for version 0.15.5 (or later revision) of CLooG... yes

[jdemeyer]

Description changed:

--- 
+++ 
@@ -8,7 +8,7 @@
 3. [attachment: 12369_doc.patch](https://github.com/sagemath/sage-prod/files/10654634/12369_doc.patch.gz) to the Sage library.

 **Testing releases**:
-1. GCC-4.6.3: [http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gcc/](http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gcc/)
+1. GCC-4.6.3: [http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta8-gcc/](http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta8-gcc/)
 2. Dependencies only: [http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gccdeps/](http://boxen.math.washington.edu/home/jdemeyer/release/sage-5.0.beta7-gccdeps/): this contains all *dependencies* of this ticket but not this ticket itself, it still includes the old Fortran spkg.

 For systems other than OS X, installing the "gccdeps" distribution is equivalent to installing the "gcc" distribution with `SAGE_INSTALL_GCC=no`.  On OS X, the "gcc" distribution normally will not build with `SAGE_INSTALL_GCC=no` because Fortran is missing.

[simon-king-jena]

comment:128

Not good.

After building the compiler with CLooG PPL support, I tried to rebuild Sage with

CFLAGS="-O3 -march=native -floop-interchange -floop-strip-mine -floop-block -fno-strict-aliasing"
export CFLAGS
CXXFLAGS="-O3 -march=native -floop-interchange -floop-strip-mine -floop-block -fno-strict-aliasing"
export CXXFLAGS

This is what (I think) was suggested on sage-devel.

However, it failed very early: It was found that the compiler can not build executables. The compiler was referred to not as gcc, but as

### Compiler was: gcc -g -O3 -march=native -floop-interchange -floop-strip-mine -floop-block

So, could it be that I misunderstood and the flags have to be passed in a different way?

[simon-king-jena]

comment:129

In the gcc man pages, I read

This optimization applies to all the languages supported by GCC and is not limited to Fortran. To use this code transformation, GCC has to be configured with --with-ppl and --with-cloog to enable the Graphite loop transformation infrastructure.

But these to options are in fact not used in the gcc spkg!

I am trying to add them (and also providing --libdir, which in some cases seems to be needed on openSuse) and try to build gcc again.

[vbraun]

comment:130

I'm pretty sure that compiling everything with -O3 + graphite will break, but I applaud your heroic effort ;-)

For the record, here is Fedora's gcc configure, that's at least one data point for how to build it:

[vbraun@volker-laptop-two ~]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC) 

It seems like you don't need any magic beyond --with-ppl and --with-cloog

[simon-king-jena]

comment:131

Replying to @vbraun:

It seems like you don't need any magic beyond --with-ppl and --with-cloog

Exactly. But the current version of this optional gcc spkg does not contain the magic.

Anyway. I am now building gcc again (after adding the magical options to spkg-install) and will report later about my heroic failures.

[jdemeyer]

comment:132

Replying to @simon-king-jena:

Exactly. But the current version of this optional gcc spkg does not contain the magic.

I don't mind adding support for this in a follow-up spkg (it's not entirely trivial, because we have to check whether CLooG is installed or not). I prefer to wait until this is reviewed and merged, to avoid rebasing in case the current spkg has problems.

[simon-king-jena]

comment:133

Replying to @jdemeyer:

Replying to @simon-king-jena: I don't mind adding support for this in a follow-up spkg (it's not entirely trivial, because we have to check whether CLooG is installed or not).

OK. But to check whether CLooG is installed should not be difficult (at least: to check whether a CLooG spkg is installed should be easy).

I prefer to wait until this is reviewed and merged, to avoid rebasing in case the current spkg has problems.

OK. But I will keep trying (and I just lost an hour compilation time because of a typo).

[jdemeyer]

comment:134

Replying to @simon-king-jena:

But to check whether CLooG is installed should not be difficult

See #12609 which deals with this kind of checks.

[simon-king-jena]

comment:135

Replying to @vbraun:

I'm pretty sure that compiling everything with -O3 + graphite will break, but I applaud your heroic effort ;-)

Then you might be surprised that the following worked:

• Build gcc via the spkg

• Build ppl (with c interface), gmp and cloog-ppl, using

  CFLAGS="-O3 -march=native"
  CXXFLAGS="-O3 -march=native"

• Build gcc again, via the modified spkg (--with-ppl --with-cloog), again with -O3 -march=native.

• Build all of Sage again (all spkgs and sage -ba), using

  CFLAGS="-O3 -march=native -floop-interchange -floop-strip-mine -floop-block -fno-strict-aliasing"
  CXXFLAGS="-O3 -march=native -floop-interchange -floop-strip-mine -floop-block -fno-strict-aliasing"

• Run more than half of sage -testall without error.

Nevertheless, it was a heroic failure.

Here are some test times without optimisation, for sage-5.0.beta7 built with my system gcc-4.6.2:

sage -t  -force_lib "devel/sage/sage/symbolic/function.pyx" 
         [3.2 s]
sage -t  -force_lib "devel/sage/sage/symbolic/benchmark.py" 
         [8.6 s]
sage -t  -force_lib "devel/sage/sage/symbolic/function_factory.py"
         [2.5 s]
sage -t  -force_lib "devel/sage/sage/symbolic/ring.pyx"     
         [4.0 s]
sage -t  -force_lib "devel/sage/sage/symbolic/relation.py"  
         [9.4 s]
sage -t  -force_lib "devel/sage/sage/symbolic/maxima_wrapper.py"
         [2.9 s]

Here are the same tests, using full optimization, using the gcc-4.6.3 from the spkg with graphite:

sage -t  -force_lib "devel/sage/sage/symbolic/function.pyx" 
         [8.0 s]
sage -t  -force_lib "devel/sage/sage/symbolic/benchmark.py" 
         [17.4 s]
sage -t  -force_lib "devel/sage/sage/symbolic/function_factory.py"
         [5.7 s]
sage -t  -force_lib "devel/sage/sage/symbolic/ring.pyx"     
         [7.8 s]
sage -t  -force_lib "devel/sage/sage/symbolic/relation.py"  
         [23.7 s]
sage -t  -force_lib "devel/sage/sage/symbolic/maxima_wrapper.py"
         [43.5 s]

What kind of optimization is it, if it makes things MASSIVELY slower???

[jdemeyer]

comment:136

I would be interesting to compare the timings with my GCC spkg, without PPL or CLooG.

[jdemeyer]

comment:137

Also: can you try exactly the same without building gmp?

[simon-king-jena]

comment:138

Replying to @jdemeyer:

Also: can you try exactly the same without building gmp?

The first thing that I had tried was building CLooG in the Sage shell. It failed during configuration and complained that it needs GMP. So, unless there is a configuration option, I don't see how MPIR could suffice.

[jdemeyer]

comment:139

Well, it could be that GMP slowed things down, not GCC.

[simon-king-jena]

comment:140

Replying to @jdemeyer:

I would be interesting to compare the timings with my GCC spkg, without PPL or CLooG.

I wonder: How could I apply all the patches to the sage root/extcode/lib repositories before Sage is built?

Or do you suggest that I start with my existing sage-5.0.beta7, and do the following:

• rm $SAGE_LOCAL/*/*gcc*
• rm -r $SAGE_LOCAL/*/*gmp*
• rm $SAGE_ROOT/spkg/installed/*
• do sage -f gcc-4.6.3.spkg, without setting compilation flags, and without the --with-ppl --with-cloog options; this would be built using my system's gcc, because of the first step
• do make, which would then use the spkg's gcc

[simon-king-jena]

comment:141

No, my previous sage-5.0.beta7 is totally messed up. I have to start from scratch.

I don't know how to do the following cleanly. Anyway, my plan is:

• untar the source ball
• type make, wait a few seconds, and interrupt, so that "./sage -sh" is available
• replace the old pari and ppl spkgs by the new ones
• provide C(XX)FLAGS="-O3 -march=native"
• install the standard mpir spkg
• install the standard (updated) ppl spkg (this is what I am doing right now)
• install the cloog_ppl spkg
• install the optional mpc spkg (I lost track where I got that from...).
• install the modified gcc spkg (using --with-ppl="$SAGE_LOCAL" --with-cloog="$SAGE_LOCAL")
• switch to C(XX)FLAGS="-O3 -march=native -floop-interchange -floop-strip-mine -floop-block -fno-strict-aliasing"
• type make and keep fingers crossed.

[jdemeyer]

comment:142

Replying to @simon-king-jena:

• type make, wait a few seconds, and interrupt, so that "./sage -sh" is available

./sage --sh should be available right after untarring. This was a consequence of #11073.

• install the optional mpc spkg (I lost track where I got that from...)

12515 (GCC needs it)