On Wed, 13 Aug 2014, Jason Merrill wrote:

> On 08/13/2014 10:28 AM, Richard Biener wrote:
> > Sofar the patch survived building stage2 in a LTO bootstrap on the
> > 4.9 branch, full testing is scheduled for trunk.
> 
> The patch breaks a lot of C++ testcases, such as
> g++.old-deja/g++.other/cvt1.C; I think you need to share the "set the
> canonical type" code with the template path.
> 
> > Jason, are you happy with that (esp. ripping out the odd
> > type completion stuff that also messes with types recorded in
> > said hashtable)?
> 
> I'm nervous about it, since it leads to ARRAY_TYPEs with different TYPE_ALIGN
> than their elements, though I'm not sure this actually breaks anything.
> Perhaps we could copy TYPE_ALIGN and TYPE_USER_ALIGN at the same place we copy
> TYPE_NEEDS_CONSTRUCTING.

Um, ok.  I don't feel like fiddling with this C++ frontend part and
am going to try workaround it in tree.c with sth like

Index: gcc/tree.c
===================================================================
--- gcc/tree.c  (revision 213814)
+++ gcc/tree.c  (working copy)
@@ -6759,6 +6759,13 @@ type_hash_canon (unsigned int hashcode,
   t1 = type_hash_lookup (hashcode, type);
   if (t1 != 0)
     {
+      if (TYPE_MAIN_VARIANT (t1) != t1)
+       {
+         /* Oops.  C++ FE fun.  Overwrite the entry.  */
+         type_hash_add (hashcode, type);
+         return type;
+       }
+      gcc_assert (TYPE_MAIN_VARIANT (t1) == t1);
       if (GATHER_STATISTICS)
        {
          tree_code_counts[(int) TREE_CODE (type)]--;

as I seem to have other GC-related LTO IL differences to chase.

So - can you take over this C++ frontend issue?

Thanks,
Richard.

Reply via email to