Re: Using MPC Library with GCC

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

From: "Mark Mitchell" <mark@codesourcery.com>

> That is not a decision, however, on whether using MPC is or is not a
> good idea.  There have been objections raised to MPC, on the grounds
> that it may not build on all host systems, or that the costs it brings
> in terms of complexity of building GCC outweigh its benefits.  We should
> reach consensus on those issues before making a decision about whether
> to depend upon it.

Thanks Mark.  Although I personally felt that the GPLv3-compatible license
terms were sufficient from a legal and policy perspective, it's good to
clarify this officially for future circumstances as well as retroactively
for the libraries we already depend on.  Also I agree that the remainder of
the discussion (i.e. whether it's a "good idea" in this particular case)
should be conducted in the public forum and that's what I asked for in my
proposal to the SC.

So to address the remaining concerns, I'll first note that the portability
issue has been dealt with.  The MPC developers adopted GCC's primary and
secondary platform list to aid in the integration with GCC.  Thanks to the
participation of many developers on this list, MPC version 0.6 has been
tested successfully on all of them as well as a long list of tertiary
systems.  One or two minor nits arose in mpc-0.6 however they are in parts
of the library that I don't use inside GCC and anyway will be fixed in the
forthcoming mpc-0.6.1.  See:
http://www.multiprecision.org/index.php?prog=mpc&page=platforms

The second issue related to "cost" MPC brings vs "benefits".  To fully
explore this you have to compare it to the cost of not using MPC.  If we
don't use MPC, the fortran maintainers will have to replicate much of MPC's
functionality to support intrinsics.  It's already partially implemented for
the "easy" cases so far but several harder bits remain.  When I compare the
fortran implementation with the MPC copies, the MPC versions include extra
code to ensure last-bit accuracy whereas the fortran cases don't.  IMHO we
should leave these special math cases to experts in the field instead of
rolling our own versions of this code.  The second cost of not using MPC
means that we'll have to fix bugs in the middle end ourselves in the folding
of complex expressions.  Again, we're not best equipped to understand the
corner cases of this and why duplicate code that's already out there?  After
that, the optimizations I provided for complex builtins becomes gravy, and
that doesn't even begin to explore future uses of MPC that I haven't thought
of yet.

Sure, if you don't use complex numbers in your code you probably won't care
about this and everything becomes a "cost".  But since complex numbers are
part of the languages specs, we need to deal with it.  So from a
code-duplication standpoint, from a language conformance standpoint, from a
bugfix standpoint, and finally from an optimization standpoint, all of these
would be a win.  The downside is that you have to build and install MPC one
time, or unpack it in your GCC source dir since I provided support for
in-tree building.  Either way, it's not that hard. :-)

       --Kaveh