This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING SC members [was RE: RFA: GCC 4.2.1: Stabalizing coalesce_list's qsort]
- From: Geoffrey Keating <geoffk at apple dot com>
- To: "Dave Korn" <dave dot korn at artimi dot com>
- Cc: "'Mark Mitchell'" <mark at codesourcery dot com>, "'Nick Clifton'" <nickc at redhat dot com>, <gcc at gcc dot gnu dot org>, "'Richard Guenther'" <richard dot guenther at gmail dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: 28 Sep 2007 17:52:16 -0700
- Subject: Re: PING SC members [was RE: RFA: GCC 4.2.1: Stabalizing coalesce_list's qsort]
- References: <m3sl6ev6iq.fsf@redhat.com> <84fc9c000708220440q2da3c0a5y8fcf5c37a40c54f1@mail.gmail.com> <46CC419C.3050004@redhat.com> <46CDFD4C.9090207@codesourcery.com> <002601c7e89e$62992930$2e08a8c0@CAM.ARTIMI.COM>
"Dave Korn" <dave.korn@artimi.com> writes:
> On 23 August 2007 22:34, Mark Mitchell wrote:
>
> > I do think that generating the same code, independent of host system, is
> > a very important property of GCC's design, just like generating the same
> > code independent of whether or not we're compiling with -g.
>
> Hear, hear. I've always thought these principles were meant to be
> sacrosanct, but now I try to look it up, I don't see them explicitly
> listed in either the development methodology, the release criteria,
> or anywhere else likely-looking.
>
> Can the SC please consider adding these requirements explicitly to
> the list of "Design and Development Goals" in the mission statement?
> Or would it make more sense as part of the development methodology,
> or the portability section of the gcc-specific coding conventions?
> (Perhaps both; as a high-level goal in the mission statement, and
> with additions to the portability section of the coding conventions
> warning about issues like HOST_WIDE_INT size on 32-vs-64-bit hosts
> and not using pointers in hashes.)
As far as I know, this actually isn't a property of GCC's design, at
present.
Although the code generated is equivalent, there are a number of cases
where it is not exactly the same. I don't remember them all, but one
case was that in many places the code does something like:
some_function(gen_reg_rtx(), gen_reg_rtx());
and so details of the RTL generated depend on the order of evaluation
of function arguments. This was a big problem before we had GIMPLE,
and may still be an issue.