Re: [lto][patch] Patch to fix multiple C++ streaming issues and a residual problem with preload_common_nodes

["Diego Novillo" <dnovillo at google dot com>]

On Tue, Jul 29, 2008 at 23:32, Bill Maddox <maddox@google.com> wrote:

> @@ -2477,6 +2478,18 @@ output_global_record_start (struct outpu
>      }
>  }
>
> +#ifdef LTO_STREAM_DEBUGGING
> +static void
> +global_vector_debug (struct output_block *ob)
> +{

Needs comment.

> -  output_tree (ob, decl->decl_common.initial);			/* ??? */
> +  /* According to tree.h, the INITIAL field isn't used,
> +     but in C++, I've seen a tree_list here.  It can be
> +     full of language-specific stuff.  Omit it.  */

Perhaps we should assert that decl_common.initial has been
cleared by free_lang_specifics().

> @@ -2756,7 +2812,9 @@ output_namespace_decl (struct output_blo
>    output_tree (ob, decl->decl_common.abstract_origin);
>
>    gcc_assert (decl->decl_common.mode == 0);
> -  gcc_assert (decl->decl_common.align == 1);
> +  /* FIXME lto:  I'm seeing both 0 and 1 here, but I don't
> +     think it is meaningful.  Verify this.  */
> +  /*gcc_assert (decl->decl_common.align == 1);*/

The alignment is in principle an arbitrary number of bits.  We
should not assert anything here.


> +  else if (tag == LTO_local_type_ref)
> +    {
> +      int lv_index = lto_input_uleb128 (ib);
> +      result = data_in->local_decls [lv_index];

No space before '['

> @@ -1970,11 +1970,13 @@ common_handle_option (size_t scode, cons
>        break;
>
>      case OPT_flto:
> -      /* FIXME: This is most surely the wrong thing to do because it
> -	 will depend on the order of the options on the command line.
> -	 However, if you specify -flto, you must have dwarf2 debugging
> -	 records.  */
> -      set_debug_level (DWARF2_DEBUG, false, "2");
> +      /* FIXME lto: Formerly, we forced emission of debug records with -flto,
> +	 because they did double-duty as part of the IR.  With the new
> +	 streamer, this is no longer necessary.  Furthermore, the LTO
> +	 backend (lto1) will most likely crash if we attempt to generate
> +	 debug records, because we have started stripping out language
> +	 dependencies in the IR, choosing, for the time being, to break
> +	 debuggability.  */

No need to clarify this here.  The lto1 crashes will be more than
enough notice that debug info needs TLC.  Further, we should
probably emit an informational message in set_debug_level using
inform().

OK with those and Rafael's changes


Diego.