Re: TRANSLATION_UNIT_DECL breaks bootstrap

[Geoff Keating <geoffk at geoffk dot org>]

> From: Steven Bosscher <s.bosscher@student.tudelft.nl>
> Date: 12 Jul 2003 03:30:26 +0200

> Op za 12-07-2003, om 03:13 schreef Geoff Keating:
> > Mark Mitchell <mark@codesourcery.com> writes:
> > 
> > > Geoff --
> > > 
> > > Your patch breaks i686-pc-linux-gnu.
> > > 
> > > The problem is that there is code that expects that file-scope
> > > variables have NULL DECL_CONTEXT, and that is no longer true.
> > 
> > I hope not.  I thought I got all those places.
> 
> Well certainly something is wrong because i686 doesn't bootstrap. :-)

I don't suppose you could send me a log and/or a preprocessed source
file?  I don't have any x86 machines suitable for building GCC.

> > Steven commented:
> > 
> > > Maybe there should be a macro HAS_FILE_SCOPE in tree.h??
> 
> As I was thinking about this a little further I was wondering why
> DECL_CONTEXT should ever be NULL after this patch.  Why not just
> _always_ put a TRANSLATION_UNIT_DECL in DECL_CONTEXT if the entity is 
> global, even if gcc is not doing intermodule stuff.

I think I decided you don't want to do that if the declaration isn't
static, and there was some good reason for it, but don't remember
exactly.  Feel free to try it and tell me how it turns out :-).

> > I haven't yet found a need for it.  I think file scope (or,
> > technically, translation unit scope) is a language-specific
> > concept---I can certainly imagine languages where it is
> > meaningless---and so it probably shouldn't appear in the middle-end.
> > Usually, you want TREE_PUBLIC or TREE_STATIC or DECL_EXTERNAL instead.
> 
> Well, we should define some semantics for this; after all, trees should
> be language-independent for tree-ssa.

I agree that we should define the meaning of TRANSLATION_UNIT_DECL, at
least in some vague way ("like NAMESPACE_DECL, but doesn't have a
name"), I just don't think that we need the particular predicate you
suggested.  Could you give an example of how it would be used?

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