Bootstrap failure on irix6.5 possibly caused by new C++ parser?

[Graham Stott]

Hi Mark,

It's a memory trample bug in the new parser.

I've identified where we are trampling memory the memory. It's occuring in
cp_parser_init_declarator within this block of code

---------------------------------------------------------------------------------

   if (cp_parser_token_starts_function_definition_p (token))
     {
       if (!function_definition_allowed_p)
         {
           /* If a function-definition should not appear here, issue an
              error message.  */
           cp_parser_error (parser,
                            "a function-definition is not allowed here");
           return error_mark_node;
         }
       else
         {
           tree *ac;

           /* Neither attributes nor an asm-specification are allowed
              on a function-definition.  */
           if (asm_specification)
             error ("an asm-specification is not allowed on a function-definition");
           if (attributes)
             error ("attributes are not allowed on a function-definition");
           /* This is a function-definition.  */
           *function_definition_p = true;

           /* Thread the access checks together.  */
           ac = &access_checks;
           while (*ac)
             ac = &TREE_CHAIN (*ac);
           *ac = declarator_access_checks;

           /* Parse the function definition.  */
           decl = (cp_parser_function_definition_from_specifiers_and_declarator
                   (parser, decl_specifiers, prefix_attributes, declarator,
                    access_checks));

           /* Pull the access-checks apart again.  */
           *ac = NULL_TREE;

           return decl;
         }
     }
-------------------------------------------------------------------------------
It's the "*ac = NULL_TREE" that's trampling over memory.

I suspect we are missing a bit of GTY(()) magic for the access_checks list.

I think I can see why the access_list returned by cp_parser_stop_deferring_access_checks
are not accessible via a GTY(()) tagged root so they might be GC if collect kicks in.

Cheers
Graham