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

[Graham Stott <graham dot stott at btinternet dot com>]

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