Re: intermodule and comptypes - need some help

[Geoff Keating <geoffk at geoffk dot org>]

> X-Original-To: geoffk@foam.wonderslug.com
> From: "Zack Weinberg" <zack@codesourcery.com>
> Cc: gcc@gcc.gnu.org
> Date: Thu, 07 Aug 2003 13:59:52 -0700
> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
> X-OriginalArrivalTime: 07 Aug 2003 21:04:02.0937 (UTC) FILETIME=[6E228690:01C35D27]
> 
> Geoff Keating <geoffk@geoffk.org> writes:
> 
> > "Zack Weinberg" <zack@codesourcery.com> writes:
> >
> >> A patch I'm working on has, as a side effect, that (in intermodule
> >> mode) duplicate_decls may encounter two declarations from different
> >> translation units at any time, not just during
> >> merge_translation_unit_decls.
> >
> > I'd be interested to hear more details about how this happens.
> 
> The basic concept is, there's a scope (currently called
> external_scope) which holds all TREE_PUBLIC declarations and possibly
> some other things.  This scope is 'outer' to the file scope, and
> persists across translation units.  Declarations in there are
> invisible until a duplicate declaration of the same thing is
> encountered.
> 
> The details are complicated, but I think the result winds up being
> more straightforward and less buggy than what we have now.  If, that
> is, I can make it work.

I considered that, but stopped when I discovered

extern int x;
static int x = 2;

We might want to consider banning that (it does produce a warning
now), but I suspect someone relies on it.

There's another case that you'd want to think about.  Consider this:

====================t1.c
struct foo;
extern void x (struct foo *);
struct foo {
  int a, b;
};
====================t2.c
struct foo {
  double d;
};
void x (struct foo *y)
{
  y->d = 0;
}
====================

This is invalid code, I think, but whether it is or is not it does make
the implementation tricky: if it's valid, you want to keep information
about 't1.c::struct foo' out of t2.c, and if it's invalid you want to
detect the error even if t2.c is compiled first.

> > I expect that at some point, some type gets created without the right
> > context.  This would never have mattered before because nothing ever
> > looked at the context of types (except in the objc compiler and then
> > only in pretty special circumstances).
> 
> Thanks for the hint.  The predicate I wrote *should* work, then?

I think it would be a good thing if we arranged for it to work, yes.

> > If bootstrapping GCC is getting to be a pain, you might find the
> > attached testcase helpful; you can modify it by assigning between x_1
> > and x_2 in the different translation units, the assignment is valid in
> > -6b but invalid (and requires a diagnostic) in -6a, and yet as written
> > the two files are valid ISO C.
> 
> This is helpful, thanks, but it doesn't tickle the problem I am
> seeing.  The problem is like this:
> 
> debug.h:127: error: conflicting types for 'dwarf_debug_hooks'
> dwarfout.c:1275: error: previous declaration of 'dwarf_debug_hooks'
> 
> and, using your hint, I think I've tracked it to BLOCK_SUPERCONTEXT of
> the block that's DECL_INITIAL of each translation_unit_decl not
> getting initialized properly.  The types being handed to my predicate
> *seem* to have the right TYPE_CONTEXTs.

Is there a mistake in that paragraph?  I didn't think
translation_unit_decls have DECL_INITIAL...

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