This is the mail archive of the
mailing list for the GCC project.
Re: Why are GCC Internals not Specification Driven ?
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Seima Rao <seimarao at gmail dot com>
- Cc: NightStrike <nightstrike at gmail dot com>, Andrew Haley <aph at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 19 Dec 2016 10:45:18 +0000
- Subject: Re: Why are GCC Internals not Specification Driven ?
- Authentication-results: sourceware.org; auth=none
- References: <CAESP5aq7R=zxozDPTSJMnKWLF_TkyVCu6UssKPz97SoOXyz4Cg@mail.gmail.com> <email@example.com> <CAF1jjLswGwiPYxfzcgfa3p7CuRMCKcCT+Qi8t+wEFrWuETCt0g@mail.gmail.com> <CAESP5ar4JnxBvr_OnoGKLet7Nzfp_tycS0yPs6XDoCo4cJk=-Q@mail.gmail.com>
On 19 December 2016 at 10:17, Seima Rao wrote:
> I was referring to one of three approaches:
> i) Write a Specification document and a matching testsuite
> ii) Document _all_ data and code together with file formats
> (e.g. dumps).
> iii) Both (i) & (ii)
> (i) is easy
A functional specification would either be constantly out-of-date or
would be a lot of effort to maintain (think how many different
architectures GCC generates code for, and how often the instruction
sets for the major architectures change). There would be some
advantages to having the document in place, but only if it was
maintained very thoroughly, which is unlikely to happen IMHO.
We have testsuites. The output formats are defined by other documents
we don't control (ABI specifications, processor instruction set
references). The "UI" is defined by the manual.
Duplicating this information in other documents would be a lot of
effort and is not very compatible with the way GCC is developed. There
is no top-down design committee that oversees GCC development and
would act as gatekeepers to specification changes.
The source code, the testsuite and the manual are the specification for GCC.
> (ii) is difficult
> (iii) doesnt sell the product well
What product is being sold here?