Re: patch for merging graphite branch (before tuplification)

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Sun, Aug 3, 2008 at 9:43 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Sun, 3 Aug 2008, Richard Guenther wrote:
>
>> >> You have to get a copy of the release 0.9 of PPL from:
>> >> http://www.cs.unipr.it/ppl/Download/
>> >
>> > I see this is documented as needing (a) C++, (b) GCC 4.0.3 or later, (c)
>> > GMP compiled with the C++ interface enabled.  I believe we previously
>> > reached a conclusion that if GCC is made to require C++ it would work with
>> > any version of GCC 3.4 or later (and did not discuss the question of the
>> > GMP C++ interface).  Recall that right now the documented requirement is
>> > that a cross-compiler (so all non-Ada front ends) can be built with GCC
>> > 2.95 or later; Ada requires 3.4 or later; and any ISO C compiler should
>> > work for bootstrapping a native compiler.
>>
>> If Graphite can be disabled then the bootstrapping issue goes away as you
>> can in a first step build current GCC with C++ enabled and do a second stage
>> with Graphite enabled.
>
> The issue is not a matter of bootstrapping from the older version being
> impossible, it's a matter of making the process more and more complicated.
>
>> > At this point I think the policy questions regarding the build
>> > requirements for graphite, even as an optional feature, need to be raised
>> > on their own in a thread on the gcc list rather than buried in the patch
>> > discussion.
>>
>> I agree.  At least this is the place for requesting Host testing on
>> non-Linux hosts.
>> Note that Fedora has packages for the PPL, likewise has Debian.  I am in
>> the progress of building ones for SUSE.
>
> And what is the packaging status of the GMP C++ interface?  The PPL page
> claims it's widely not packaged.

SUSE and Debian have it, it is required by some parts of KDE for example.

> If the PPL version affects the code generated by GCC (other than simply
> through bugs in PPL) and so the configure tests need to test for *exactly*
> a particular version (that we put in the infrastructure directory in
> gcc.gnu.org) that complicates use of distributor versions in that each GCC
> version will have a required PPL version that may not be the particular
> one distributed.  The distributor might override the configure check for
> building their own GCC version, as one of the modifications to it - but as
> far as possible unmodified FSF GCC should have deterministic code
> generation not depending on the versions of libraries it is linked
> against, which could limit the utility of distributor versions for people
> building FSF GCC themselves on the various distributions.

Sure.  But modulo bugs there shouldn't be a difference in code-generation
(for the PPL part at least), as it provides "basic math" like mpfr.  Code
generation could be affected by the version of Cloog though.

Richard.