Use of the __GMP_CC and __GMP_CFLAGS macros

[Vincent Lefevre]

On 2012-10-05 13:54:12 +0200, Marc Glisse wrote:
> On Mon, 24 Sep 2012, Vincent Lefevre wrote:
> 
> >The __GMP_CC and __GMP_CFLAGS macros were introduced in gmp.h so that
> >the GMP user (in particular, MPFR) doesn't have to guess which ABI GMP
> >chose (and how to use it) when it was built and installed, in case GMP
> >didn't select the default ABI. You can read the full discussion here:
> >
> > https://sympa.inria.fr/sympa/arc/mpfr/2008-07/msg00010.html
> >
> >The problem is that distributions (like Debian) could have built GMP
> >under a particular environment and provide packages with a gmp.h using
> >__GMP_CC and __GMP_CFLAGS values from this environment, which may not
> >match what is expected on the end user machine. The differences could
> >be, e.g.:
> > * a compiler that isn't necessarily installed or have a unusual name
> >   (for instance, Debian uses x86_64-linux-gnu-gcc);
> 
> And x86_64-linux-gnu-gcc is installed with the gcc package, it isn't very
> hard to find.

The gcc package is not necessarily installed. The user may have
installed gcc from upstream or chosen a different compiler via
the /usr/bin/cc alternative.

Note also that even if the user has chosen to install the gcc package,
the current situation could also be problematic in the future, if
other flags are added: GMP could be built with a recent gcc, but the
user could have kept an old version, where the flag isn't supported
(or is still experimental and is broken).

> If you use a different toolchain, of course you can't blindly
> reuse options from another toolchain.
> 
> > * suboptimal compiler options (for instance, Debian uses -O3 without
> >   architecture information, which may generate code slower than with
> >   -O2, at least this happened in the past).
> 
> Preference for -O2 is a matter of taste. It it was changed to -O2, I could
> complain that it is suboptimal and should be -O3, which for a number of
> applications does produce faster code than -O2.

What is best for GMP isn't necessarily the best for other
applications. Unless there is some good reason (see the ABI related
problems), the choice of the optimization should not come from the
GMP maintainer, but from the application itself.

> Lack of architecture information: the gmp package was compiled to work on
> generic machines, it seems natural to keep compiling for a generic target.
> If you want machine-specific options, you are the one doing something
> special, and you can either add them yourself or recompile gmp specifically
> for your machine.

I'm not talking about GMP, but about applications that link against
GMP.

> Now we can discuss removing these lines as a possible enhancement. It could
> be as easy as adding a couple lines to the doc: "Distributors who provide
> GMP packages for the default architecture of their platform, with only
> generic optimization options, are advised to remove those 2 lines which
> would provide no useful information and could mislead users". We could even
> add a configure option --disable-compile-flags-in-gmp-h to help.
> 
> Would that be ok with everyone? Vincent, do you want to provide the patch?

There is a private discussion about changing the doc (and whether
something should be changed in GMP's configure), and I've already
proposed some text.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)