Opened 7 years ago

Closed 7 years ago

Last modified 6 years ago

#12751 closed defect (fixed)

Allow building Sage with GCC-4.7.x

Reported by: mariah Owned by: GeorgSWeber
Priority: critical Milestone: sage-5.2
Component: build Keywords: GCC 4.7.0 C++11 -fpermissive compiler bugs sd40.5
Cc: jdemeyer, leif Merged in: sage-5.2.beta1
Authors: Jeroen Demeyer Reviewers: Volker Braun
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by leif)

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

  • GFan: #12760
  • Givaro: #12761
  • LinBox: #12762
  • PolyBoRi: #12750, #12655
  • MPIR on ia64 (Itanium): #12765 (GCC bug) -- #11616 also provides an MPIR 2.4.0.p3 spkg working around this.
  • MPFR on ia64 (Itanium): #12837 (same GCC bug) -- Note that MPFR is also a prerequisite for building the GCC spkg.
  • GMP-ECM on ia64 (Itanium): Fixed by #12830 (same GCC bug)
  • zn_poly on ia64 (Itanium): Fixed by #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: #12800
  • eclib on Solaris (See comments below; this is a Solaris header issue, fixed by a new spkg at #10993.)
  • FLINTQS on Solaris: #12855 (Also a subtle Solaris header issue.)
  • Support GCC version "4.7": #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 #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 #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 #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 #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:

Attachments (5)

ecm-6.3.p8.diff (6.9 KB) - added by jdemeyer 7 years ago.
Diff for the ecm spkg. For reference / review only.
mpfr-3.1.0.p2.diff (5.5 KB) - added by jdemeyer 7 years ago.
Diff for the mpfr spkg. For reference / review only.
mpir-2.4.0.p6.diff (3.0 KB) - added by jdemeyer 7 years ago.
Diff for the mpir spkg. For reference / review only.
zn_poly-0.9.p9.diff (3.1 KB) - added by jdemeyer 7 years ago.
Diff for the zn_poly spkg. For reference / review only.
12751_allow_gcc_4_7.patch (1.5 KB) - added by jdemeyer 7 years ago.
Apply to SAGE_ROOT

Download all attachments as: .zip

Change History (71)

comment:1 Changed 7 years ago by jdemeyer

  • Cc jdemeyer added
  • Description modified (diff)
  • Summary changed from make sage build with gcc-4.7 to Sage fails to build with GCC-4.7.0

comment:2 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:3 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:4 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:5 follow-ups: Changed 7 years ago by leif

  • Cc leif added
  • Description modified (diff)
  • Keywords GCC 4.7.0 C++11 added

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.

comment:6 Changed 7 years ago by leif

  • Description modified (diff)

comment:7 in reply to: ↑ 5 Changed 7 years ago by leif

Replying to leif:

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.)

comment:8 in reply to: ↑ 5 Changed 7 years ago by leif

Replying to leif:

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).

comment:9 in reply to: ↑ 5 ; follow-up: Changed 7 years ago by leif

Replying to leif:

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.)

comment:10 in reply to: ↑ 9 ; follow-up: Changed 7 years ago by leif

Replying to leif:

Replying to leif:

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.

comment:11 follow-up: Changed 7 years ago by jdemeyer

  • Priority changed from critical to blocker

comment:12 in reply to: ↑ 11 ; follow-up: Changed 7 years ago by leif

Replying to jdemeyer:

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

comment:13 in reply to: ↑ 12 Changed 7 years ago by jdemeyer

Replying to leif:

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

No, but you should ask William Stein.

comment:14 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:15 Changed 7 years ago by leif

  • Description modified (diff)

comment:16 Changed 7 years ago by leif

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.

comment:17 Changed 7 years ago by leif

  • Description modified (diff)

comment:18 Changed 7 years ago by leif

  • Description modified (diff)
  • Keywords -fpermissive compiler bugs added

comment:19 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:20 Changed 7 years ago by leif

  • Description modified (diff)

comment:21 follow-up: Changed 7 years ago by leif

I get a build error for the (old) eclib spkg on Solaris [SPARC, 32-bit]:

...
g++ -c -fPIC -g -O2 -DNEW_OP_ORDER -DUSE_PARI_FACTORING -DNTL_ALL -I/home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/include -I/home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/include arith.cc -o arith_n.o
In file included from arith.cc:24:0:
arith.h: In function 'int div(long int, long int)':
arith.h:182:39: error: 'int div(long int, long int)' conflicts with previous using declaration 'std::ldiv_t std::div(long int, long int)'
make[3]: *** [arith_n.o] Error 1
make[3]: Leaving directory `/home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/spkg/build/eclib-20100711.p0/src/procs'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/spkg/build/eclib-20100711.p0/src'
Error building eclib

real    0m9.843s
user    0m5.982s
sys     0m0.474s
************************************************************************
Error installing package eclib-20100711.p0
************************************************************************

Haven't yet tried the new autotools-enabled upstream package; a new spkg should be posted soon on #10993, hopefully...

comment:22 in reply to: ↑ 21 ; follow-ups: Changed 7 years ago by leif

Replying to leif:

I get a build error for the (old) eclib spkg on Solaris [SPARC, 32-bit]:

...
arith.h:182:39: error: 'int div(long int, long int)' conflicts with previous using declaration 'std::ldiv_t std::div(long int, long int)'
...

Haven't yet tried the new autotools-enabled upstream package; a new spkg should be posted soon on #10993, hopefully...

It fails in the same way; yet I have no idea why this only fails on Solaris, as AFAIK

std::ldiv_t std::div(long int, long int)

is pretty C++98. Maybe on Solaris just some using namespace std; gets pulled in, which isn't present on other systems.

comment:23 in reply to: ↑ 22 ; follow-up: Changed 7 years ago by leif

Replying to leif:

Replying to leif:

I get a build error for the (old) eclib spkg on Solaris [SPARC, 32-bit]:

...
arith.h:182:39: error: 'int div(long int, long int)' conflicts with previous using declaration 'std::ldiv_t std::div(long int, long int)'
...

[...] I have no idea why this only fails on Solaris, as AFAIK

std::ldiv_t std::div(long int, long int)

is pretty C++98. Maybe on Solaris just some using namespace std; gets pulled in, which isn't present on other systems.

Apparently Solaris' /usr/include/stdlib.h is the culprit:

/*
 * Copyright 2004 Sun Microsystems, Inc.  All rights reserved.
 * Use is subject to license terms.
 */

/*      Copyright (c) 1988 AT&T */
/*        All Rights Reserved   */

/*      THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T     */
/*      The copyright notice above does not evidence any        */
/*      actual or intended publication of such source code.     */

#ifndef _STDLIB_H
#define _STDLIB_H

#pragma ident   "@(#)stdlib.h   1.51    04/06/30 SMI"   /* SVr4.0 1.22  */

#include <iso/stdlib_iso.h>
#include <iso/stdlib_c99.h>

#if defined(__EXTENSIONS__) || defined(_XPG4)
#include <sys/wait.h>
#endif

/*
 * Allow global visibility for symbols defined in
 * C++ "std" namespace in <iso/stdlib_iso.h>.
 */
#if __cplusplus >= 199711L
...
using std::div;
...

comment:24 Changed 7 years ago by leif

Minimal example:

// div.cc

#include <cstdlib>

int div(long a, long b)
{
  return 0;
}

This fails with GCC 4.7.0 on Solaris, while it doesn't on (e.g.) Linux.

comment:25 Changed 7 years ago by leif

  • Description modified (diff)

comment:26 in reply to: ↑ 22 Changed 7 years ago by leif

  • Description modified (diff)

Replying to leif:

Replying to leif:

I get a build error for the (old) eclib spkg on Solaris [SPARC, 32-bit]:

...
arith.h:182:39: error: 'int div(long int, long int)' conflicts with previous using declaration 'std::ldiv_t std::div(long int, long int)'
...

Haven't yet tried the new autotools-enabled upstream package; a new spkg should be posted soon on #10993, hopefully...

It fails in the same way; yet I have no idea why this only fails on Solaris, as AFAIK

std::ldiv_t std::div(long int, long int)

is pretty C++98. Maybe on Solaris just some using namespace std; gets pulled in, which isn't present on other systems.

Now fixed in the new upstream tarball (eclib-2012-04-15.tar.gz), by renaming the function. (See #10993.)

comment:27 Changed 7 years ago by leif

  • Description modified (diff)

comment:28 Changed 7 years ago by leif

  • Description modified (diff)

Added a reference to the GMP-ECM spkg ticket working around the bug on ia64.

comment:29 Changed 7 years ago by leif

  • Description modified (diff)

comment:30 Changed 7 years ago by leif

  • Description modified (diff)

comment:31 in reply to: ↑ 23 Changed 7 years ago by leif

Replying to leif:

Replying to leif:

Replying to leif:

I get a build error for the (old) eclib spkg on Solaris [SPARC, 32-bit]:

...
arith.h:182:39: error: 'int div(long int, long int)' conflicts with previous using declaration 'std::ldiv_t std::div(long int, long int)'
...

[...] I have no idea why this only fails on Solaris, as AFAIK

std::ldiv_t std::div(long int, long int)

is pretty C++98. Maybe on Solaris just some using namespace std; gets pulled in, which isn't present on other systems.

Apparently Solaris' /usr/include/stdlib.h is the culprit [...]

See #12855 for a similar issue with the FLINTQS spkg, showing up as an ambiguous call of log() due to definitions from math.h (which puts all overloaded functions also into the global namespace).

comment:32 Changed 7 years ago by leif

Perhaps doesn't really belong to this ticket, but now also PPL fails to build -- more precisely install -- (with GCC 4.7.0) on Solaris (SPARC; mark2):

libtool: install: strip --strip-debug /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZN22Parma_Watchdog_Library7HandlerD5Ev
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZNK22Parma_Watchdog_Library16Handler_Function3actEv
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZN22Parma_Watchdog_Library16Handler_FunctionD1Ev
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZN22Parma_Watchdog_Library16Handler_FunctionD0Ev
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZN22Parma_Watchdog_Library7HandlerD0Ev
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZN22Parma_Watchdog_Library4InitC5Ev
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZN22Parma_Watchdog_Library5EListINS_15Pending_ElementINS_4TimeEEEED5Ev
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZTSN22Parma_Watchdog_Library7HandlerE
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZTIN22Parma_Watchdog_Library7HandlerE
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZTSN22Parma_Watchdog_Library16Handler_FunctionE
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZTIN22Parma_Watchdog_Library16Handler_FunctionE
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZTVN22Parma_Watchdog_Library7HandlerE
BFD: /home/leif/Sage/release/build/mark2/sage-5.0.beta13-gcc-4.7.0/local/lib/libpwl.a(Watchdog.o): no group info for section .group%_ZTVN22Parma_Watchdog_Library16Handler_FunctionE
BFD: BFD (GNU Binutils) 2.22 internal error, aborting at ../../binutils-2.22/bfd/elf.c line 2905 in bfd_elf_set_group_contents

BFD: Please report this bug.

comment:33 in reply to: ↑ 10 Changed 7 years ago by leif

Replying to leif:

Replying to leif:

Replying to leif:

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.

On 32-bit Solaris SPARC (skynet machine mark2), R segfaults during byte-compiling package "base" when compiled with -O3; using -O2 instead apparently works.

(The setup -- when just sourcing /usr/local/skynet_bash_profile -- on the Solaris machines is currently quite broken anyway. In addition, R 2.14.0 messes up LD_LIBRARY_PATH such that the dynamic linker picks up an incompatible [and totally outdated] version of libgcc_s.so.1, so R cannot be run, which of course breaks the build as well. A work-around is to create a symbolic link to the proper version in e.g. $SAGE_LOCAL/lib/.)

comment:34 Changed 7 years ago by leif

  • Description modified (diff)

comment:35 Changed 7 years ago by jdemeyer

  • Priority changed from blocker to critical

Since the GCC spkg "fixes" all of these except for MPIR and MPFR, this won't be a blocker.

comment:36 Changed 7 years ago by leif

  • Description modified (diff)

The zn_poly spkg from #12433 now also works around the GCC 4.7.0 bug on Itanium.

comment:37 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:38 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:39 Changed 7 years ago by jdemeyer

  • Keywords sd40.5 added

comment:40 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:41 Changed 7 years ago by jdemeyer

The ia64 bug is fixed in SVN now, tested on Skynet cleo (build + ptestlong passed).

comment:42 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:43 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:44 Changed 7 years ago by jdemeyer

  • Authors set to Jeroen Demeyer
  • Description modified (diff)

comment:45 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:46 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:47 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:48 Changed 7 years ago by jdemeyer

  • Milestone changed from sage-5.1 to sage-5.0.1

comment:49 Changed 7 years ago by jdemeyer

  • Description modified (diff)
  • Status changed from new to needs_review

Changed 7 years ago by jdemeyer

Diff for the ecm spkg. For reference / review only.

Changed 7 years ago by jdemeyer

Diff for the mpfr spkg. For reference / review only.

Changed 7 years ago by jdemeyer

Diff for the mpir spkg. For reference / review only.

Changed 7 years ago by jdemeyer

Diff for the zn_poly spkg. For reference / review only.

Changed 7 years ago by jdemeyer

Apply to SAGE_ROOT

comment:50 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:51 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:52 Changed 7 years ago by jdemeyer

  • Description modified (diff)

comment:53 follow-ups: Changed 7 years ago by vbraun

  • Reviewers set to Volker Braun
  • Status changed from needs_review to positive_review

Well testing on skynet might be a bit difficult, but it works for me on Fedora 17 (which ships gcc 4.7.0). 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 ;)

comment:54 in reply to: ↑ 53 Changed 7 years ago by jdemeyer

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.

comment:55 Changed 7 years ago by jdemeyer

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.

comment:56 Changed 7 years ago by jdemeyer

  • Description modified (diff)
  • Milestone changed from sage-5.0.1 to sage-5.2
  • Summary changed from Sage fails to build with GCC-4.7.0 to Allow building Sage with GCC-4.7.x

comment:57 Changed 7 years ago by leif

  • Description modified (diff)

GCC 4.7.1 has been released on June 14th.

comment:58 in reply to: ↑ 53 ; follow-up: Changed 7 years ago by leif

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... ;-)

comment:59 in reply to: ↑ 58 ; follow-up: Changed 7 years ago by vbraun

Replying to leif:

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.

comment:60 in reply to: ↑ 59 Changed 7 years ago by leif

Replying to vbraun:

Replying to leif:

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.

comment:61 follow-up: Changed 7 years ago by 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.

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.

comment:62 in reply to: ↑ 61 Changed 7 years ago by jdemeyer

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.

comment:63 Changed 7 years ago by leif

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.

comment:64 Changed 7 years ago by jdemeyer

  • Merged in set to sage-5.2.beta1
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:65 follow-up: Changed 6 years ago by leif

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!)

comment:66 in reply to: ↑ 65 Changed 6 years ago by leif

Replying to leif:

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.

Note: See TracTickets for help on using tickets.