First, as a general principle I don't think it's really a good idea to
have the documentation for specs duplicated in two places. It would be
better to have it in exactly one place, and so avoid having two copies
getting out of sync in future.
I'd say that specs are an internal implementation detail, liable to change
in future releases without worrying about backwards compatibility (beyond
the basic cases such as the example of --with-specs given in
install.texi), and so the user manual should only have a brief description
and a reference to gcc.c for the details of what individual specs do,
rather than listing the details of each individual spec. That would mean
making sure the comments in gcc.c give all the information currently in
invoke.texi from "Here is a table of all defined @samp{%}-sequences"
onwards, and then replacing that text in invoke.texi with a reference to
gcc.c. (I'm less sure about the earlier parts of the description of spec
files in invoke.texi, but I think everything describing the individual
spec characters and functions makes more sense in gcc.c.)
This patch says "The @code{sanitize} spec function takes no arguments.",
but actually it appears to take one argument.
--
Joseph S. Myers
jos...@codesourcery.com
