Re: RFC/RFHelp: c-decl.c rewrite - almost but not quite

[Geoff Keating <geoffk at desire dot geoffk dot org>]

> From: Zack Weinberg <zack@codesourcery.com>
> Date: Wed, 31 Mar 2004 18:40:52 -0800

> Geoff Keating <geoffk@geoffk.org> writes:
> >
> > I am a little bit concerned about part of this approach.  It's
> > possible to have distinct declarations for the same object in the same
> > translation unit that are not the same (and so cannot be represented
> > by the same DECL in the front-end).  In the backend, you can collapse
> > them, but in the front-end you'll need to keep them distinct so that
> > you know when to issue diagnostics (and possibly for correctness in
> > other ways, I would have to think about that).
...
> > Note that the C standard in 6.7 only says:
> >
> >   All declarations in the same scope that refer to the same object or
> >   function shall specify compatible types.
> >
> > These declarations are not in the same scope, so this doesn't apply.
> 
> There's also the stronger statement in 6.2.7p2:
> 
>   All declarations that refer to the same object or function shall
>   have compatible type; otherwise the behavior is undefined.

Aargh!  I missed that statement.  This is a better example:

int foo_A (void) {
  extern int foo[100];
  return foo[0];
}

int foo_B (void) {
  extern int foo[];
  return sizeof (foo);  // error
}

In this example, the two foo declarations are of compatible type, by
6.7.5.2 paragraph 6:

 For two array types to be compatible, both shall have compatible
 element types, and if both size specifiers are present ... shall have
 the same constant value.

3.3 correctly diagnoses:

t.c: In function `foo_B':
t.c:8: error: invalid application of `sizeof' to an incomplete type

but HEAD accepts this invalid program.  The diagnostic is mandatory,
by 6.5.3.1 paragraph 1:

  The sizeof operator shall not be applied to an expression that has
  function type or an incomplete type ...

I am not sure whether this is fatal to the idea of having a single
DECL even during parsing.  If this is the only case where two types
can be compatible but significantly different, then I think you could
evaluate some sizeof() expressions as they are encountered during
parsing, and change the DECL so that it always has the 'current' type.
However, this might become complicated in the case where there are
also 'foo' declarations in outer scopes, you'd have to maintain a
stack of the types.  (You would also need to make sure that this
really is the only case.)

What was your plan for making IMA work?  Although my previous example
wasn't valid when you have both routines in one file, you can
certainly have something like it across multiple files.  It seems that
if you want to end up with one DECL, you'll have to either start with
one and modify that DECL during parsing in what seems likely to be a
complicated way (even more complicated than my suggestion above), or
have multiple DECLs and then replace each place that uses them.

> >> The combination of struct c_binding and IDENTIFIER_NODE is what I was
> >> thinking of.  We have to allocate something like 40 bytes to represent
> >> an identifier bound to a single DECL, which is by far the most common
> >> case.  I have some ideas for how to improve this - e.g. using just a
> >> single chain of bindings, and you have to look for the one you want -
> >> but I am not sure they're actually performance wins.
> >
> > I am also concerned about the performance impact.  Allocating and
> > filling in memory is known to be a performance problem in GCC: GCC does
> > too much of it.  Did you do any performance measurements of this
> > patch?
> 
> No; however, I have reason to believe that it is faster, as it avoids
> several lengthy linked-list operations.  As I said, I have ideas for
> how to improve performance without sacrificing correctness.

I think we need measurements before we can commit to this design.

Please understand, this is a critical issue.  If we've switched one
obscure set of bugs for a different obscure set of bugs, that might be
progress; but if we've done this *and made the compiler significantly
slower*, then we'd be better off without the change.

-- 
- Geoffrey Keating <geoffk@geoffk.org>