[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933 --- Comment #15 from Leif Leonhardy --- (In reply to Richard Biener from comment #14) > Fixed. In trunk that is. In GCC 6.1.0 we still have $ egrep -iw 'gmp|mpfr|mpc' src/gcc-6.1.0/contrib/download_prerequisites MPFR=mpfr-2.4.2 GMP=gmp-4.3.2 MPC=mpc-0.8.1 wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPFR.tar.bz2 || exit 1 tar xjf $MPFR.tar.bz2 || exit 1 ln -sf $MPFR mpfr || exit 1 wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$GMP.tar.bz2 || exit 1 tar xjf $GMP.tar.bz2 || exit 1 ln -sf $GMP gmp || exit 1 wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPC.tar.gz || exit 1 tar xzf $MPC.tar.gz || exit 1 ln -sf $MPC mpc || exit 1 (Same for GCC 4.9.4, released today. And we of course keep getting reports about 't-scan' failing in GMP 4.3.2 on gmp-bugs@...)
[Bug c/63484] misleading/obsolete -fdelete-null-pointer-checks documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63484 Leif Leonhardy changed: What|Removed |Added CC||bugfeed at online dot de --- Comment #1 from Leif Leonhardy --- As of GCC 6.1.0, the documentation has slightly changed: -fdelete-null-pointer-checks Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. This option enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that a memory access to address zero always results in a trap, so that if a pointer is checked after it has already been dereferenced, it cannot be null. Note however that in some environments this assumption is not true. Use -fno-delete-null-pointer-checks to disable this optimization for programs that depend on that behavior. This option is enabled by default on most targets. On Nios II ELF, it defaults to off. On AVR and CR16, this option is completely disabled. Passes that use the dataflow information are enabled independently at different optimization levels.
[Bug web/60933] Please do not advertise outdated version of gmp, mpfr, mpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60933 --- Comment #11 from Leif Leonhardy --- (In reply to Jonathan Wakely from comment #2) > We've had situations in the past where the minimum suggested versions work > and the latest versions prevented GCC from building. Well, in the past... ;-) > The suggested versions > are known to work and have been thoroughly tested, which might not be true > of the latest versions. Sure. But note that this is not (or no longer) true for at least GMP 4.3.2, assuming "works" includes "the library's test suite passes [when compiled] with GCC". I.e., GMP 4.3.2's test suite contains a subtle bug (fixed long ago, in all later versions) that will cause a single test (t-scan) to fail when compiled with GCC 4.8.0 and any later version; it only incidentally doesn't show up with earlier ones. While the bug doesn't affect the library code or GCC itself, it is annoying to users building GCC as well, as most won't know until they report it to gmp-bugs, which happens pretty often. (In fact, the error message of course asks them to do so. And people are encouraged to run 'make check'.)
[Bug tree-optimization/56982] [4.8/4.9 Regression] Bad optimization with setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #10 from Leif Leonhardy 2013-04-18
01:17:31 UTC ---
"One proposed requirement on setjmp is that it be usable like any other
function, that is, that it be callable in *any* expression context, and that
the expression evaluate correctly whether the return from setjmp is direct or
via a call to longjmp. Unfortunately, any implementation of setjmp as a
conventional called function cannot know enough about the calling environment
to save any temporary registers or dynamic stack locations used part way
through an expression evaluation. [...] The temporaries may be correct on the
initial call to setjmp, but are not likely to be on any return initiated by a
corresponding call to longjmp. These considerations dictated the constraint
that setjmp be called only from within fairly simple expressions, ones not
likely to need temporary storage.
An alternative proposal considered by the C89 Committee was to require that
implementations recognize that calling setjmp is a special case, and hence that
they take whatever precautions are necessary to restore the setjmp environment
properly upon a longjmp call. This proposal was rejected on grounds of
consistency: implementations are currently allowed to implement library
functions specially, but no other situations require special treatment."
So according to this (The C99 Rationale [1], page 139 ff., likewise the Single
UNIX Specification), here setjmp() is simply used in an invalid context (i.e.,
in an assignment statement). ;-)
Still, with -Og at least, GCC 4.8.0 produces wrong code even if setjmp() is
used in an "allowed" context (as in e.g. if (setjmp(...)>0) ..., or switch
(setjmp(...)) { ... }), and no matter whether n is declared volatile or not.
[1] http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
[Bug c/53662] Cannot build static gcc on i686 linux gnu with -m64 support.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53662 Leif Leonhardy changed: What|Removed |Added CC||bugfeed at online dot de --- Comment #4 from Leif Leonhardy 2012-11-26 04:01:07 UTC --- (In reply to comment #2) > (In reply to comment #1) > > > > That means you need a 64-bit capable binutils. > > > > Just a guess, but you might need to use --target=x86_64-unknown-linux-gnu to > > make a cross compiler for x86_64, which will be multilib-capable by > > default. > > To do that you'll need a 64-bit binutils and 64-bit glibc. > > > > This should really be dealt with on the gcc-help mailing list, I don't think > > it's a bug. > > Sorry, I meant that this might be bug in gcc bootstrap stage. As I said, I > have > compiled binutils with --enable-multilib ... I could try --enable-64-bit-bfd > tough. That's not what you /could try/, that's what you *have to* do... ;-) I.e., configure binutils with '--enable-64-bit-bfd --enable-targets=all' (e.g.), otherwise the built 'gas' bails out on '--64'. -leif P.S.: I'm currently trying to build a "multilib" GCC 4.7.2 on a Pentium4 (a.k.a. i786), i.e., x86 system. Build goes fine until libquadmath's 'configure' tries to *run* executables built with '-m64' (which of courseTM cannot work). No idea why it's attempting that -- probably because host==build==target==pentium4-linux-gnu and it doesn't notice that we're "cross-compiling" in the 64/ directory. The other libs built just fine (e.g. libssp).
[Bug rtl-optimization/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 --- Comment #20 from Leif Leonhardy 2012-04-09 16:42:38 UTC --- (In reply to comment #16) > It is time to do something as GCC 4.7 is quite hampered by this on IA-64. Indeed. Besides MPIR (hence presumably also GMP) and NTL, also MPFR, GMP-ECM, PARI, FLINT and some other less prominent packages fail to build due to this error (unless one specifies `-O0 ...`).
[Bug rtl-optimization/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload in libffi/src/ia64/ffi.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #15 from Leif Leonhardy 2012-04-05
18:03:31 UTC ---
Just for the record:
Also MPIR 2.1.3, MPIR 2.4.0 and NTL 5.5.2 fail to build, with the same error
message ("error: ‘asm’ operand requires impossible reload").
Work-around for MPIR: Compile with (e.g.) '-O0 -finline-functions
-fschedule-insns', which of course is quite odd.
$ uname -rsm
Linux 2.6.16.46-0.12-default ia64
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7.0/ia64-Linux-suse/libexec/gcc/ia64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: ia64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.7.0/src/gcc-4.7.0/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-as=/usr/local/binutils-2.22/ia64-Linux-suse-gcc-4.6.2/bin/as
--with-gnu-ld
--with-ld=/usr/local/binutils-2.22/ia64-Linux-suse-gcc-4.6.2/bin/ld
--with-gmp=/usr/local/mpir-2.5.1/ia64-Linux-suse-gcc-4.6.2
--with-mpfr=/usr/local/mpfr-3.1.0/ia64-Linux-suse-mpir-2.5.1-gcc-4.6.2
--with-mpc=/usr/local/mpc-0.9/ia64-Linux-suse-mpir-2.5.1-mpfr-3.1.0-gcc-4.6.2
--prefix=/usr/local/gcc-4.7.0/ia64-Linux-suse
Thread model: posix
gcc version 4.7.0 (GCC)
