Call for MPC complex math library GCC testers on various platforms
I'm hoping to integrate GCC with the complex math library MPC. You can read the gory details here: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00671.html To ensure widespread portability, the MPC developers are keeping track of the platforms where the latest MPC works here: http://www.loria.fr/~zimmerma/free/mpc.html If you would like to help out by testing MPC on your favorite platforms (especially those from the GCC primary/secondary platform list) then please download the latest MPC tarball from the above LORIA link and send your results to the MPC mailing list here: http://lists.gforge.inria.fr/mailman/listinfo/mpc-discuss The results of a "./configure; make; make check" plus the compiler, MPFR and GMP versions and target triplet you used would be useful feedback. If you have any problems on your box, patches to get it working would of course be greatly appreciated. Thanks, --Kaveh -- Kaveh R. Ghazi
Re: Minimum GMP/MPFR version bumps for GCC-4.5
From: "Joe Buck" Debian stable, and Ubuntu Hardy (most recent LTS release) have 2.3.1. Same with OpenSUSE 11.0. So I think 2.3.1 is typical of current stable releases; Fedora tends to be bleeding edge and not typical. I still have to deal with older distros (e.g. RHEL 4), but it's already necessary to use newer gmp and gas versions, as well as a newer mpfr version, in that case. Thanks to all who responded. Based on the various feedback, it seem like for most (all?) people their box arrives with a recent enough GMP/MPFR or they already have to get a sufficiently recent copy from source and build it in-tree. So upgrading GCC's requirements to gmp-4.2 and mpfr-2.3.1 should be minimally disruptive. I'll prepare a patch for 4.5. Regards, --Kaveh
Re: Minimum GMP/MPFR version bumps for GCC-4.5
From: "Steven Bosscher" The problem doesn't happen on machines I own or have root access to. It's only a problem when you try to do gcc development on machines hosted by 3rd parties (SF compile farm, HP cluster, machines at places where I work and/or where I try to convince people to use gfortran instead of e.g. sunf90, etc.). I've frequently been in those situations, especially evangelizing GCC on non-linux-gnu where you never have GMP/MPFR by default. In that case you simply drop the necessary tarballs of GMP/MPFR in your GCC source dir and do an in-tree build of the whole lot. For the MPC library integration, the patches I posted support in-tree builds for MPC as well. So there's no loss of this workaround for the situation you described. Anyway I think that's tangential to the topic at hand, this isn't really the MPC thread. Here's it's only whether it's okay (i.e. low disruption) to upgrade to gmp-4.2 (three year old release) and mpfr-2.3.1 (a micro bump above what we require now). Based on my own observations and what othes have said here, it seems to me that either you already have the necessary versions supplied by your distro, or you've already had to go through the trouble of getting a recent release. I haven't heard of anyone who would have previously gotten the software by default and would now have to do an extra manual step. Even if there were, it's not such a big deal IMHO to get the packages and drop them in your gcc sources. --Kaveh
Re: gcc-4.1-20080303 is now available
From: "Richard Guenther" <[EMAIL PROTECTED]> I support the final-release-then-close approach. But can we get a volunteer to convert that branch to GPLv3... ? I strongly object to moving the 4.1 brach to GPLv3. Richard. Because... ? -- Kaveh R. Ghazi
Re: C++ Warnings on trunk
From: "Ian Lance Taylor" <[EMAIL PROTECTED]> Kaveh mentioned these in his original e-mail, explained why he found it difficult to fix, and added this to the Makefile so that it wouldn't break the build. # bitmap.c contains -Wc++compat warnings. bitmap.o-warn = -Wno-error This too should be fixed soon but need not be fixed immediately. Ian Right, here's the original link where I mention it: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01658.html This involves a cast from one type to another through a void*. I haven't been able to convince myself that this is completely safe. If someone understands why the code is violating type-safety intentionally and can explain why it's always safe, I would be happy to insert the appropriate cast and fix it.
