From: "Mark Mitchell" <m...@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
