PCH patch installed in my mainline tree, testing now

[Geoffrey Keating]

On Tuesday, April 15, 2003, at 11:22  PM, Loren James Rittle wrote:

[lots of fun stuff about PCH deleted.]

> Humm, how about emitcount (a static nested inside a static function):
>
> [...]
> static int
> maybe_emit_file (fileno)
>      int fileno;
> {
>   static int emitcount = 0;
> [...]
>
> Why does an int need to be marked as a root?  I take it the GC
> documentation isn't doing PCH enough justice yet?  I.e. we have to
> mark things other than roots, eh?  The issue of what PCH requirements
> on marking aren't spelled out completely (however, I'll wing it).

Yes, I should add some documentation about what PCH needs.

> Is it legal to mark a static so hidden?  The point is moot since it is
> buried way down inside a conditional compilation...

No, you can't mark static that are not file-scope; not for any deep 
reasons, it's just that there's no way to get their address.  (If we 
could require ELF and GCC, then I could write some nice macros to allow 
marking such objects, but that would kind of defeat the purpose of GCC. 
  I'd really like to be able to write 'maybe_emit_file::emitcount'...  
but that ability would defeat the usual purpose of making them 
block-scope.)

> Consulting doc/gty.texi and what you did, I pulled it out, like so:
>
> + /* Number of file tables emited in maybe_emit_file(). */
> + static GTY(()) int emitcount = 0;
>
> #ifdef DWARF2_DEBUGGING_INFO
>
> make check-g++ RUNTESTFLAGS\='pch.exp' - all FAILs gone
> make check-gcc RUNTESTFLAGS\='pch.exp' - all FAILs gone
>
> Yup, that fixed it. ;-)
>
> However, I still see a few excess FAILs in `gmake check' in
> libstdc++-v3 (see above) when PCH is enabled.  There are a few other
> statics buried within that final mega DWARF2_DEBUGGING_INFO section of
> dwarf2out.c.  Some are used in a pseudo-persistent manner (i.e. to
> return a value with limited lifetime).  Those require no marking, eh?

Yes, if a variable isn't live over a PCH dump or a GGC collection, it 
doesn't need to be marked.  For example, print_indent doesn't need 
marking since it's used only while outputting a DIE and we don't dump 
PCH files half-way through outputting a DIE.

By comparison, label_num in gen_internal_sym does need to be marked.  I 
couldn't find any others.

> There are others that must be persistent for the duration of gcc like
> emitcount.  Do all of them need to be hoisted and marked?

Yes, they probably do.

>   Is it ever
> wrong to hoist and mark?  BTW, why can't they be marked in place?  I
> think DWARF2_DEBUGGING_INFO is set constant by configure/config files
> yet I note that you went out of your way to remove the conditionals
> (and/or hoist them).

The gengtype program that does this marking doesn't understand 
#if/#endif at all, so if you don't move the variables out of the 
conditionals you'll get a build failure on systems where 
DWARF2_DEBUGGING_INFO isn't defined.

> Is this correct marking:
>
> static GTY((length ("fde_table_allocated"))) dw_fde_ref fde_table;
> static unsigned fde_table_allocated;
>
> ?
>
> Contrast to this case where the referenced length was also explicitly
> marked:
>
> static GTY((length ("decl_die_table_allocated"))) dw_die_ref 
> *decl_die_table;
> static GTY(()) unsigned decl_die_table_allocated;

No, this is almost always wrong; they both need to be marked.

> I hope you don't mind the questions.  I understand boehm-gc fairly
> well but this is the first "static marking GC", I've seen.  Feel free
> to cut-n-paste and answer in public so others can see.

Thanks for your suggestions, I'll make a patch and post it for testing.

-- 
Geoff Keating <geoffk@apple.com>