Upgrading to GCC 4.7.2

[Jeroen Demeyer]

The Cygwin folks have an issue that GCC-4.6.3 doesn't compile ECL
properly due to a GCC bug
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061).

Since this problem doesn't seem to occur with GCC-4.7.2, I would propose
to upgrade Sage's GCC to version 4.7.2. There already exists an optional
package for this, so basically we just need to make that optional
package standard. Several of the buildbots are already using GCC-4.7.x
or even GCC-4.8-trunk, so GCC-4.7.x should be well-tested by now and I
don't expect problems. If nobody complains, I will do this upgrade to
GCC-4.7.2.

Note that upgrading to versions >=4.8.0 of GCC might be harder since
those versions are implemented in C++.

[kcrisman]

On Thursday, March 7, 2013 4:38:37 AM UTC-5, Jeroen Demeyer wrote:

The Cygwin folks have an issue that GCC-4.6.3 doesn't compile ECL
properly due to a GCC bug
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061).

Since this problem doesn't seem to occur with GCC-4.7.2, I would propose
to upgrade Sage's GCC to version 4.7.2. There already exists an optional

I assume this would mostly be to avoid the need to install not just gcc, but g++ and gfortran on Cygwin?  Otherwise it hardly seems worth the effort.   Given that we aren't intending for most Cygwin folks to have to actually build from source, maybe this isn't necessary.  Alternately, the default Cygwin install seems to come with gcc3, and perhaps that could be used to build the Sage gcc package... I guess it would be interesting to hear more about this.  How does the gcc-4.7 spkg do on various Mac systems?

[Jeroen Demeyer]

On 2013-03-07 14:16, kcrisman wrote:
> Alternately,
> the default Cygwin install seems to come with gcc3, and perhaps that
> could be used to build the Sage gcc package...

No, the whole point of this thread is that the Sage gcc-4.6.3 fails to
build ECL in Cygwin (and the Cygwin default gcc-3.x would not manage to
build Sage either). Hence the proposal to upgrade the Sage GCC package.

[leif]

Jeroen Demeyer wrote:
> The Cygwin folks have an issue that GCC-4.6.3 doesn't compile ECL
> properly due to a GCC bug
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061).
>
> Since this problem doesn't seem to occur with GCC-4.7.2, I would propose
> to upgrade Sage's GCC to version 4.7.2.

+1 (not just for better supporting Cygwin)

We can still keep the GCC 4.6.3 spkg in optional (or archive?).


-leif

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[kcrisman]

On Thursday, March 7, 2013 8:16:30 AM UTC-5, kcrisman wrote:

On Thursday, March 7, 2013 4:38:37 AM UTC-5, Jeroen Demeyer wrote:

The Cygwin folks have an issue that GCC-4.6.3 doesn't compile ECL
properly due to a GCC bug
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061).

Since this problem doesn't seem to occur with GCC-4.7.2, I would propose
to upgrade Sage's GCC to version 4.7.2. There already exists an optional

I assume this would mostly be to avoid the need to install not just gcc, but g++ and gfortran on Cygwin?  Otherwise it hardly seems worth the effort.   Given that we aren't intending for most Cygwin folks to have to actually build from source, maybe this isn't necessary.  Alternately, the default Cygwin install seems to come with gcc3, and perhaps that could be used to build the Sage gcc package... I guess it would be interesting to hear more about this.  How does the gcc-4.7 spkg do on various Mac systems?

No doctest failures on ptestlong on Mac OS X 10.7. 

[John H Palmieri]

On Thursday, March 7, 2013 5:16:30 AM UTC-8, kcrisman wrote:

How does the gcc-4.7 spkg do on various Mac systems?

On OS X 10.8.2: I built Sage 5.8.beta3 + the gcc 4.7.2 spkg, and all tests passed (make ptestlong). On another 10.8.2 machine, I built Sage 5.8.beta4 + gcc 4.7.2 with SAGE_CHECK=yes. Except for the usual failure with zn_poly, all tests passed.

--
John

[leif]

Jeroen Demeyer wrote:
> The Cygwin folks have an issue that GCC-4.6.3 doesn't compile ECL
> properly due to a GCC bug
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061).
>
> Since this problem doesn't seem to occur with GCC-4.7.2, I would propose
> to upgrade Sage's GCC to version 4.7.2. There already exists an optional
> package for this, so basically we just need to make that optional
> package standard. Several of the buildbots are already using GCC-4.7.x
> or even GCC-4.8-trunk, so GCC-4.7.x should be well-tested by now and I
> don't expect problems. If nobody complains, I will do this upgrade to
> GCC-4.7.2.

Just noticed there are still subtle issues with GCC 4.7.x on Solaris
(due to its math headers).

Singular 3-1-5.p4 doesn't yet build because of these; I'll see whether
there are more instances (i.e., spkgs) later...

(We already fixed FLINTQS and eclib which had the same problem.)

[John Cremona]

On 14 March 2013 13:42, leif <not.r...@online.de> wrote:
>
>
> Just noticed there are still subtle issues with GCC 4.7.x on Solaris (due to
> its math headers).
>
> Singular 3-1-5.p4 doesn't yet build because of these; I'll see whether there
> are more instances (i.e., spkgs) later...
>
> (We already fixed FLINTQS and eclib which had the same problem.)

Do I know about this? I certainly want to know if any changes are
needed to eclib so I can change them myself (i.e. upstream), you
should not need any patching for Sage.

John

[kcrisman]

On OS X 10.4 PPC, I do get a failure in building the spkg.

libtool: compile: /Users/student/Desktop/sage-5.8.beta4/spkg/build/
gcc-4.7.2.p0/gcc-build/./gcc/xgcc -B/Users/student/Desktop/
sage-5.8.beta4/spkg/build/gcc-4.7.2.p0/gcc-build/./gcc/ -B/Users/
student/Desktop/sage-5.8.beta4/local/powerpc-apple-darwin8.11.0/bin/ -
B/Users/student/Desktop/sage-5.8.beta4/local/powerpc-apple-
darwin8.11.0/lib/ -isystem /Users/student/Desktop/sage-5.8.beta4/local/
powerpc-apple-darwin8.11.0/include -isystem /Users/student/Desktop/
sage-5.8.beta4/local/powerpc-apple-darwin8.11.0/sys-include -
DHAVE_CONFIG_H -I. -I../../../src/libitm -I../../../src/libitm/config/
powerpc -I../../../src/libitm/config/posix -I../../../src/libitm/
config/generic -I../../../src/libitm -Wall -pthread -Werror -g -O2 -MT
sjlj.lo -MD -MP -MF .deps/sjlj.Tpo -c ../../../src/libitm/config/
powerpc/sjlj.S -fno-common -DPIC -o .libs/sjlj.o
../../../src/libitm/config/powerpc/sjlj.S:155:Invalid mnemonic 'FUNC'
../../../src/libitm/config/powerpc/sjlj.S:250:Invalid mnemonic 'CALL'
../../../src/libitm/config/powerpc/sjlj.S:259:Invalid mnemonic 'END'
../../../src/libitm/config/powerpc/sjlj.S:262:Invalid mnemonic
'HIDDEN'
../../../src/libitm/config/powerpc/sjlj.S:263:Invalid mnemonic 'FUNC'
../../../src/libitm/config/powerpc/sjlj.S:407:Invalid mnemonic 'END'
make[7]: *** [sjlj.lo] Error 1
make[6]: *** [all-recursive] Error 1
make[5]: *** [all] Error 2
make[4]: *** [all-target-libitm] Error 2
make[3]: *** [all] Error 2

This seems to be more or less the same as gcc bug 52482 (and I find no
other references to this error)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52482

We have here in compilation

"AS=/Users/student/Desktop/sage-5.8.beta4/spkg/build/gcc-4.7.2.p0/gcc-
build/./gcc/as"

but otherwise I don't know where the problem might be. You'd think
that using gcc's own as would work for building gcc.

[leif]

I probably should have added "long time ago".

You fixed this (the problem with div() on Solaris with GCC 4.7.x) in
eclib-2012-04-15 (cf. #10993), before the new eclib went into Sage.

[John Cremona]

Thanks,

John

>
>
> -leif
>
> --
> () The ASCII Ribbon Campaign
> /\ Help Cure HTML E-Mail
>

> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[leif]

leif wrote:
> Just noticed there are still subtle issues with GCC 4.7.x on Solaris
> (due to its math headers).
>
> Singular 3-1-5.p4 doesn't yet build because of these; I'll see whether
> there are more instances (i.e., spkgs) later...

Nope, Singular is the only spkg, and I now recall that I previously
(about 11 month ago) managed to build all of Sage with GCC 4.7.0 on
Solaris, so the problem with Singular was introduced when upgrading it.

The fix is easy though (adding casts on three lines of bigintmat.cc).

[Julien Puydt]

Le 15/03/2013 10:10, leif a �crit :

> The fix is easy though (adding casts on three lines of bigintmat.cc).

Please don't forget to push that fix upstream!

Snark on #sage-devel

[leif]

Jeroen Demeyer wrote:
> The Cygwin folks have an issue that GCC-4.6.3 doesn't compile ECL
> properly due to a GCC bug
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061).
>
> Since this problem doesn't seem to occur with GCC-4.7.2, I would propose
> to upgrade Sage's GCC to version 4.7.2. There already exists an optional
> package for this, so basically we just need to make that optional
> package standard. Several of the buildbots are already using GCC-4.7.x
> or even GCC-4.8-trunk, so GCC-4.7.x should be well-tested by now and I
> don't expect problems. If nobody complains, I will do this upgrade to
> GCC-4.7.2.

Just for the record, I get ICEs with the GCC 4.7.2.p0 spkg (with Sun as
and ld) on Solaris SPARC (32-bit) when compiling GAP and libGAP with
-O3; -O2 works in both cases. (I didn't get them with the system-wide
GCC 4.7.0 on {mark,mark2}.)

[Probably more to come; haven't yet investigated further either.]

[Jean-Pierre Flori]

I'm currently rebuilding Sage using only Sun ld and as (my previous attempt used the GNU ones and presented some problems).
The first failure I encountered was Singular, but that's the restrict keyword crap I already mentioned, and is not GCC 4.7.2 related.

[Jean-Pierre Flori]

On Saturday, March 30, 2013 7:15:10 AM UTC+1, leif wrote:

Jeroen Demeyer wrote:
> The Cygwin folks have an issue that GCC-4.6.3 doesn't compile ECL
> properly due to a GCC bug
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061).
>
> Since this problem doesn't seem to occur with GCC-4.7.2, I would propose
> to upgrade Sage's GCC to version 4.7.2. There already exists an optional
> package for this, so basically we just need to make that optional
> package standard. Several of the buildbots are already using GCC-4.7.x
> or even GCC-4.8-trunk, so GCC-4.7.x should be well-tested by now and I
> don't expect problems. If nobody complains, I will do this upgrade to
> GCC-4.7.2.

Just for the record, I get ICEs with the GCC 4.7.2.p0 spkg (with Sun as
and ld) on Solaris SPARC (32-bit) when compiling GAP and libGAP with
-O3; -O2 works in both cases.  (I didn't get them with the system-wide
GCC 4.7.0 on {mark,mark2}.)

I cannot reproduce these on the Solaris I have access to (same as the one with singular/restrict problem).
With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should not make any difference), I can build the GAP and libgap spkgs both with CFLAGS unset and with CFLAGS="-O3".
 

[leif]

Jean-Pierre Flori wrote:
> On Saturday, March 30, 2013 7:15:10 AM UTC+1, leif wrote:
> Just for the record, I get ICEs with the GCC 4.7.2.p0 spkg (with Sun as
> and ld) on Solaris SPARC (32-bit) when compiling GAP and libGAP with
> -O3; -O2 works in both cases. (I didn't get them with the system-wide
> GCC 4.7.0 on {mark,mark2}.)
>
> I cannot reproduce these on the Solaris I have access to (same as the
> one with singular/restrict problem).
> With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should not make any
> difference), I can build the GAP and libgap spkgs both with CFLAGS unset
> and with CFLAGS="-O3".

I also built GCC itself with -O3 (and -mcpu=ultrasparc3
-mtune=ultrasparc3); not yet sure whether that matters.


-leif

> [Probably more to come; haven't yet investigated further either.]

[Jean-Pierre Flori]

On Saturday, March 30, 2013 2:46:56 PM UTC+1, leif wrote:

Jean-Pierre Flori wrote:
> On Saturday, March 30, 2013 7:15:10 AM UTC+1, leif wrote:
>     Just for the record, I get ICEs with the GCC 4.7.2.p0 spkg (with Sun as
>     and ld) on Solaris SPARC (32-bit) when compiling GAP and libGAP with
>     -O3; -O2 works in both cases.  (I didn't get them with the system-wide
>     GCC 4.7.0 on {mark,mark2}.)
>
> I cannot reproduce these on the Solaris I have access to (same as the
> one with singular/restrict problem).
> With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should not make any
> difference), I can build the GAP and libgap spkgs both with CFLAGS unset
> and with CFLAGS="-O3".

I also built GCC itself with -O3 (and -mcpu=ultrasparc3
-mtune=ultrasparc3); not yet sure whether that matters.

I rebuilt GCC with CFLAGS="-O3 -mcpu=niagara2 -mtune=niagara2".
And ... tada! It breaks when building GAP:
 {{{
../../src/blister.c: In function 'InitKernel':
../../src/blister.c:2743:1: internal compiler error: in simplify_immed_subreg, at simplify-rtx.c:5262
}}}
three times.

[Jean-Pierre Flori]

On Saturday, March 30, 2013 6:25:37 PM UTC+1, Jean-Pierre Flori wrote:

On Saturday, March 30, 2013 2:46:56 PM UTC+1, leif wrote:

Jean-Pierre Flori wrote:
> On Saturday, March 30, 2013 7:15:10 AM UTC+1, leif wrote:
>     Just for the record, I get ICEs with the GCC 4.7.2.p0 spkg (with Sun as
>     and ld) on Solaris SPARC (32-bit) when compiling GAP and libGAP with
>     -O3; -O2 works in both cases.  (I didn't get them with the system-wide
>     GCC 4.7.0 on {mark,mark2}.)
>
> I cannot reproduce these on the Solaris I have access to (same as the
> one with singular/restrict problem).
> With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should not make any
> difference), I can build the GAP and libgap spkgs both with CFLAGS unset
> and with CFLAGS="-O3".

I also built GCC itself with -O3 (and -mcpu=ultrasparc3
-mtune=ultrasparc3); not yet sure whether that matters.

I rebuilt GCC with CFLAGS="-O3 -mcpu=niagara2 -mtune=niagara2".
And ... tada! It breaks when building GAP:
 {{{
../../src/blister.c: In function 'InitKernel':
../../src/blister.c:2743:1: internal compiler error: in simplify_immed_subreg, at simplify-rtx.c:5262
}}}
three times.

No problems with the same GCC built with CFLAGS="-O3 -mcpu=niagara2 -mtune=niagara2" if I build GAP with CFLAGS="-O2".

[leif]

Exactly.

> three times.
>
> No problems with the same GCC built with CFLAGS="-O3 -mcpu=niagara2
> -mtune=niagara2" if I build GAP with CFLAGS="-O2".

Yep. Although I didn't get them with GCC 4.7.0 and '-mcpu=...
-mtune=... -O3', so this might be a regression in 4.7.1 or 4.7.2.

Did you search GCC bugzilla? (I haven't yet.)


-leif

[Jean-Pierre Flori]

Nope, I rather tried to finish building Sage.
Here is the result of "make ptestlong":
{{{
sage -t --long devel/sage/sage/crypto/mq/sr.py  # 1 doctest failed
sage -t --long devel/sage/sage/interfaces/expect.py  # 2 doctests failed
sage -t --long devel/sage/sage/matrix/matrix_modn_dense.pyx  # 5 doctests failed
sage -t --long devel/sage/sage/matrix/matrix_modn_dense_template.pxi  # 5 doctes
ts failed
sage -t --long devel/sage/sage/combinat/backtrack.py  # Time out
sage -t --long devel/sage/sage/combinat/cluster_algebra_quiver/cluster_seed.py 
# Time out
sage -t --long devel/sage/sage/combinat/cluster_algebra_quiver/mutation_type.py
 # Time out
sage -t --long devel/sage/sage/combinat/cluster_algebra_quiver/quiver.py  # Time
 out
sage -t --long devel/sage/sage/rings/polynomial/polynomial_element.pyx  # 1 doct
est failed
sage -t --long devel/sage/sage/interfaces/ecm.py  # Time out
sage -t --long devel/sage/sage/quadratic_forms/quadratic_form__automorphisms.py
 # Time out
sage -t --long devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py  #
Time out
}}}

The non-timeout errors are worrying:
* sage.crypto.mq.sr.test_consistency
{{{
      File "multi_polynomial_ideal_libsingular.pyx", line 250, in sage.rings.polynomial.multi_polynomial_ideal_libsingular.slimgb_libsingular (sage/rings/polynomial/multi_polynomial_ideal_libsingular.cpp:3568)
    RuntimeError: Bus error
}}}
* sage.interface.expect: Singular crashes
* sage.matrix.matrix_modn_dense.Matrix_modn_dense._unpickle: unpickle failures
{{{
      File "matrix_modn_dense_template.pxi", line 640, in sage.matrix.matrix_modn_dense_double.Matrix_modn_dense_template._pickle (sage/matrix/matrix_modn_dense_double.cpp:6719)
    RuntimeError: Bus error
}}}
* matrix.matrix_modn_dense_template.Matrix_modn_dense_template._unpickle: unpickle failures.
except for
* sage.rings.polynomial.polynomial_element.Polynomial.inverse_mod: likely numerical noise

Of course all these failures might be GCC 4.7.2 non-related.

[Jean-Pierre Flori]

It does not errors out if I only use -O3 and not -mtune and -mcpu.

[Jean-Pierre Flori]

And does with "-O3 -mcpu=niagara2"

[Jeroen Demeyer]

On 03/30/2013 09:23 PM, Jean-Pierre Flori wrote:
> The non-timeout errors are worrying:

These are known errors: #13151

[Jeroen Demeyer]

Buildbot reports no problems at all with the new GCC spkg using
*default* CFLAGS, so I really think it is ready:

http://trac.sagemath.org/sage_trac/ticket/14378

[Jean-Pierre Flori]

I agree, but it would be nice to report the corenrcase problems we encounter upstream, although I don't think Ill be able to track this down.

[leif]

I don't think it is unusual to have GCC configured to generate (more)
native code by default; in that case the CFLAGS Sage is built with
don't really matter.

To me, "supported platform" doesn't mean "there exists a machine I can
build Sage on [if I build and use Sage's GCC spkg]".

At the very least, we should record / document issues with other
constellations. It's IMHO ok to rely on Sage's GCC if we encounter a
GCC version which is more or less broadly known to be broken [on
platform xy], but we shouldn't make building Sage's GCC a general
prerequisite, nor should we limit testing to just the latter case,
otherwise problems -- whether upstream or within Sage -- will never get
fixed.

[Jeroen Demeyer]

On 04/01/2013 04:43 PM, leif wrote:
> To me, "supported platform" doesn't mean "there exists a machine I can

> build Sage on.
I think it should mean: Sage works using the *default* options, assuming
the documented prerequisites are met. If you manually set
SAGE_INSTALL_GCC or CFLAGS or whatever, don't expect it to work.

[leif]

What are "default options"? As mentioned, the build on Solaris SPARC is
borken if just GCC is reasonably configured -- no need to set CFLAGS,
SAGE_INSTALL_GCC, or the latter plus GCC_CONFIGURE.


Just as an example, #14265 (which solves a regression) shows that
apparently nobody ever tested building Sage on Solaris* with GCC 4.7.x
after #13237 got merged -- i.e., since Sage 5.4.beta0 (!), released
September 10th 2012 (about half a year after GCC 4.7.0 had been
released, about three months after GCC 4.7.1 had been released, and a
few days before GCC 4.7.2 got released).


-leif

______
* the arch/CPU type doesn't matter