Fix PR62077

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


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

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

Thanks,
Richard.

On Thu, 14 Aug 2014, Richard Biener wrote:

> 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)]--;

Awww, and that quickly runs into a bootstrap ICE like

In file included from 
/abuild/rguenther/obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/rope:2975:0,
                 from 
/space/rguenther/src/svn/trunk/libstdc++-v3/include/precompiled/extc++.h:52:
/abuild/rguenther/obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/ropeimpl.h:1185:52: 
internal compiler error: canonical types differ for identical types const 
long unsigned int [46] and const long unsigned int [46]
     _S_min_len[int(__detail::_S_max_rope_depth) + 1] = {

Richard.

On 08/14/2014 05:07 AM, Richard Biener wrote:
> So - can you take over this C++ frontend issue?

OK.

Jason