This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: patch for merging graphite branch (before tuplification)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Sebastian Pop <sebpop at gmail dot com>, Richard Guenther <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, David Edelsohn <edelsohn at gmail dot com>, "Harle, Christophe" <christophe dot harle at amd dot com>, Tobias Grosser <grosser at fim dot uni-passau dot de>, Konrad Trifunovic <konrad dot trifunovic at gmail dot com>, Albert Cohen <Albert dot Cohen at inria dot fr>, Roberto Bagnara <bagnara at cs dot unipr dot it>
- Date: Mon, 4 Aug 2008 10:27:31 +0000 (UTC)
- Subject: Re: patch for merging graphite branch (before tuplification)
- References: <cb9d34b20807251914jb7fb76q4452be18461d7464@mail.gmail.com> <84fc9c000807260228h12552595x17b2a7556d35913b@mail.gmail.com> <cb9d34b20808021726w3dcb5015o9b256ef393dba02c@mail.gmail.com> <Pine.LNX.4.64.0808031809020.15922@digraph.polyomino.org.uk> <84fc9c000808031220t14f60e5bie1760eaaa413aeb5@mail.gmail.com> <Pine.LNX.4.64.0808031925260.15922@digraph.polyomino.org.uk> <84fc9c000808031320m153160b0l60db9d80b1f58742@mail.gmail.com> <cb9d34b20808031330m6a38c120hbe4a1a971030f17d@mail.gmail.com> <Pine.LNX.4.64.0808032038410.15922@digraph.polyomino.org.uk> <48965D2E.4020207@codesourcery.com>
On Sun, 3 Aug 2008, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
> > 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.
>
> I agree with this statement of principle.
>
> There is a logical extreme of this that I think unreasonable; for example, if
> we depend on the C library to do something, and it does it wrong on some host,
> then we may lose -- and it's not practical to include the C library as part of
> the compiler sources. But, people should know how to get reference versions
> of core computational libraries, and I know you're not arguing for the logical
> extreme.
And we do make sure to avoid depending on areas where C library behavior
is unspecified - in particular we make sure qsort comparison functions do
not compare distinct values as equal so there is only one correct output
order from any call to qsort, even if this means as a last resort
comparing based on values that are arbitrary (e.g. DECL_UID) but stable
across hosts.
> I'm not sure, however, that we need to try too hard to prevent people using
> other versions. We just need to say "the version we used is X; if you want to
> try some other version, your mileage may vary." We need to agree on X
> (including what version is to be used on branches vs. mainline) so that if you
> report a bug in my change and I go to fix it I don't get confused because you
> and I are using different versions. A warning seems appropriate, but an error
> seems strong.
I think an error is right, to make it clear quite what the optimizers in
GCC version x.y are. One possibility would be a --with-cloog-version
configure option, where the default is whatever the standard versions for
that GCC version is; that way a different version could be used but it
would be shown in the GCC configure options what the particular version
was; an error would be given if the version present at configure time, or
at run time, was not that named in the configure option. (If distributors
wish to link against a shared library, a
--disable-runtime-cloog-version-check option could be provided as well to
allow a version later than that configured with to be used at runtime.)
--
Joseph S. Myers
joseph@codesourcery.com