This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why are GCC Internals not Specification Driven ?

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

I disagree.

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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]