Re: forcing tail/sibling call optimization

["Joseph S. Myers" <jsm28@cam.ac.uk>]

On Sun, 26 Nov 2000, Robert Dewar wrote:

> I think there is real merit in providing fairly formal specifications
> for GNU C enhancements for three reasons.
>
> 1. The attempt to produce a FFS can often reveal difficulties that are
> not apparent in a less formal approach.
>
> 2. If other C compilers want to copy the feature, which I assume we
> welcome, then there is a clear guide.
>
> 3. If the ISO committee wants to copy the feature, which I assume
> we welcome, then there is a clear guide.

Indeed, it seems fairly impossible at present to work out what the
specification of most GNU C extensions is supposed to be.

A few months ago I noted problems with statement expressions.  (See c/772
for conclusions from that long discussion.)

Consider __attribute__, one of the most useful and widely used extensions.

The syntax is nowhere specified.  This was noted over three years ago
( http://bugs.debian.org/12253 - no documentation of where to put an
attribute on a function definition).

Attributes on labels seem not to be properly documented.  The docs for
-Wunused-label say you can put the "unused" attribute on a label, but the
syntax is nowhere stated.

Attributes do not work properly inside nested declarators - many of them
should apply to a function type but instead apply only to a function
declaration.  The grammar has them as parts of declarations instead of
parts of declarators, but function attributes clearly ought to be adding
alternatives to the productions "direct-declarator: direct-declarator (
parameter-type-list )" and "direct-declarator: direct-declarator (
identifier-list_opt )" (from C99).  Some attributes, if they can get
parsed, do get attached to the function type (e.g. noreturn), but others
don't; e.g. the format attributes work by adding to a list of format
functions stored by DECL_NAME and DECL_ASSEMBLER_NAME (for C++ mangled
names).

The rules for composite types and compatible types in the presence of
attributes are nowhere specified.  Different attributes need to work
differently here; those such as "const" and "format" that say more about
the type need to work differently from those such as "packed" that change
the type.  Some of this is implemented (e.g. the internal use of "const"
and "volatile" on function types is special cased to be different from
that on object types), but it isn't documented.

The grammar is also full of conflicts relating to attributes.  There used
to be a comment listing the conflicts that was removed because it was so
out of date, but their presence perhaps indicates lack of careful design.
Nowhere does the manual describe the conflicts and what the parsing rules
are supposed to be (ideally the intended rules were checked against the
parser resolution, but I strongly suspect that people have just increased
the %expect value to quiet Bison rather than checking carefully in each
case).

I strongly agree that GCC extensions should have formal specifications (in
the form of changes to the C99 or C++ grammar, as appropriate, plus
specifications of constraints, semantics, and undefined behaviour).

-- 
Joseph S. Myers
jsm28@cam.ac.uk