patch for merging graphite branch (before tuplification)

[Joseph S. Myers]

On Sun, 3 Aug 2008, Sebastian Pop wrote:

> I don't see the point on imposing Cloog to generate the same loops
> output for all the versions.  On the contrary, the output of Cloog
> should improve with time, i.e.  reducing the number of redundant
> constraints is one of the optimizations that Cloog can do, and that we
> should improve.
> 
> Preventing people to use newer versions of Cloog is not an option.

GCC 4.4 -fwhatever should generate the same results everywhere.  I think 
reproducibility of results across hosts, for the same compiler sources, is 
a critical matter.  This means release branches must require a particular 
version, and check the version when the compiler executes if linking 
against a Cloog shared library is supported.  The Cloog version number 
scheme will need to allow this, and release tarballs may need to go in the 
infrastructure directory.

Now, someone might modify their release branch copy to allow a more recent 
version.  But it should be quite clear that this is a modification to FSF 
GCC, just like backporting an optimization from trunk to your copy of a 
release branch is a modification to FSF GCC.  Cloog is effectively part of 
the GCC optimizers for this purpose, and should be frozen except for bug 
fixes on entering Stage 3 just like the rest of the optimizers.

The configure checks could be written to check DEV-PHASE, allow anything 
new enough on trunk and only a fixed release on release branches, just 
like the --enable-checking configure support depends on DEV-PHASE.  That 
might give the right convenience of development against new versions while 
ensuring GCC releases have well-determined results.

(But importing Cloog into the GCC repository and using the imported 
version unconditionally would avoid these problems; the imported version 
would automatically branch along with GCC - again, a distributor could 
choose to modify GCC to link with a system shared library of a newer 
version.  It does, however, require FSF approval.)

-- 
Joseph S. Myers
joseph@codesourcery.com