This is the mail archive of the
gcc@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: GCC Mailing List <gcc at gcc dot gnu dot org>
- Cc: Richard Guenther <richard dot guenther at gmail dot com>, Sebastian Pop <sebpop at gmail dot com>, Mark Mitchell <mark at codesourcery dot com>, 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: Sun, 3 Aug 2008 20:36:53 +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> <489608FB.3040508@starynkevitch.net>
On Sun, 3 Aug 2008, Basile STARYNKEVITCH wrote:
> I also am in favor of having some stuff in GCC which use external libraries,
> provided this stuff can be disabled at configure time.
My view as a general principle is that options such as -O2 must have
exactly the same results regardless of how GCC is configured, whether -g
is used (apart from debug info differences), whether precompiled headers
are used, what host GCC is running on, what libraries it uses, what
versions of them it uses or how those libraries are configured. So
anything optional can't be included in an option that's supported with it
missing; any option enabling an optional feature must give an error if the
relevant code is not linked in.
Any differences in code generated (or diagnostics given, etc.) based on
the above factors are bugs. Of course such bugs exist, but we should take
reasonable care about not introducing new ones. This means obvious things
such as not putting an optional feature into an option that is accepted
without the feature enabled, as well as checking new host libraries for
how they might affect the above.
Separately, we know that options not included in -On are liable to bit-rot
so we need to be quite careful when adding them, balancing the risks of
bit-rot and the costs of additional build dependencies, together with how
advantageous the option would be likely to be in -On.
--
Joseph S. Myers
joseph@codesourcery.com