[Bug lto/41598] New: bootstrap *using* lto fails

[Bug lto/41598] New: bootstrap *using* lto fails

[espindola at google dot com]

To reproduce with the delta reduced test

cc1 dwarf2out.i -quiet -O2 -flto -o dwarf2out.s
as -V -Qy -o dwarf2out.o dwarf2out.s
cc1 c-decl.i -quiet -O2  -flto -o c-decl.s 
as -V -Qy -o c-decl.o c-decl.s
lto1 -quiet -O2 c-decl.o dwarf2out.o -o /dev/null

Produces:
------------------------------------------------
In function 'gt_pch_p_20VEC_die_arg_entry_gc':
lto1: error: type mismatch in address expression
union tree_node * *

union tree_node *

D.2877_8 = &x_3->base.vec[i0_1].arg;

lto1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
------------------------------------------------------


-- 
           Summary: bootstrap *using* lto fails
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: espindola at google dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[espindola at google dot com]

------- Comment #1 from espindola at google dot com  2009-10-05 23:12 -------
Created an attachment (id=18716)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18716&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[espindola at google dot com]

------- Comment #2 from espindola at google dot com  2009-10-05 23:12 -------
Created an attachment (id=18717)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18717&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-06 10:15 -------
Can you specify how you bootstrapped with LTO (did you use the linker plugin
and thus dragged in libbackend.a)?

lto1: error: type mismatch in address expression
union tree_node * *

union tree_node *

this is a missed type merging / completion.  There are likely very many
of this kind - can you try with type-checking disabled?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[espindola at google dot com]

------- Comment #4 from espindola at google dot com  2009-10-06 12:37 -------
I was trying to do a manual bootstrap. Just compiled a gcc with
--disable-bootstrap --with-ld=gold and used that to try to build a new one:

CC="$HOME/gcc/inst/bin/gcc -flto -use-linker-plugin" ../gcc-git/configure
--enable-lto --enable-gold  --with-ld=$HOME/binutils/inst/bin/ld
--enable-languages=c --disable-bootstrap

will try again with type-checking disabled.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2009-10-06 12:45 -------
Further reducing into an obviously equivalent header appreciated.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[espindola at google dot com]

------- Comment #6 from espindola at google dot com  2009-10-06 13:55 -------
Created an attachment (id=18722)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18722&action=view)
testcase


-- 

espindola at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #18716|0                           |1
        is obsolete|                            |
  Attachment #18717|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[espindola at google dot com]

------- Comment #7 from espindola at google dot com  2009-10-06 13:56 -------
Created an attachment (id=18723)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18723&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[espindola at google dot com]

------- Comment #8 from espindola at google dot com  2009-10-06 13:56 -------
Created an attachment (id=18724)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18724&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2009-10-11 15:13 -------
Ok, so the issue here is that we have

  typedef struct VEC_constructor_elt_gc { } VEC_constructor_elt_gc;

vs.

  typedef struct VEC_constructor_elt_gcx { } VEC_constructor_elt_gc;

which causes us to not merge the two union tree_node types which are

  typedef union tree_node *tree;
  union tree_node {
    tree * use;
    VEC_constructor_elt_gc *elts;
  };

And in the end because we look through typedefs here:

  static hashval_t
  iterative_hash_type_name (tree type, hashval_t v)
  {
    tree name = TYPE_NAME (TYPE_MAIN_VARIANT (type));

Now this is necessary - we'd want to merge

  union tree_node {
    tree * use;
    struct VEC_constructor_elt_gc *elts;
  };

as well.

So - this cannot be fixed by type merging, but instead together with what
we need to fix TBAA issues for non-merged types we have to try to cover
these issues as well.

Now - a C language lawyer could chime in here and tell us if the above
invokes undefined behavior.  Short:

 typedef struct A {} T;
 typedef struct B {} T;

is this valid cross translation-unit if T is used across units?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-10-11 15:13:42
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

Re: [Bug lto/41598] bootstrap *using* lto fails

[Andrew Pinski]

On Sun, Oct 11, 2009 at 8:13 AM, rguenth at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
> is this valid cross translation-unit if T is used across units?


Yes this is valid for C.  In C, types are across TUs are not based on
names.  This is why the code for -combine was complex with respect of
type equality.

-- Pinski

[Bug lto/41598] bootstrap *using* lto fails

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2009-10-11 15:33 -------
Further reduced testcase:

b.h
---
typedef union tree_node *tree;
union tree_node {
    tree * use;
    VEC_constructor_elt_gc *elts;
};

t1.c:
-----
typedef struct VEC_constructor_elt_gc { } VEC_constructor_elt_gc;
#include "b.h"
struct stmt_tree_s {
    tree x_cur_stmt_list;
};
void *add_stmt (struct stmt_tree_s *x)
{
  return &x->x_cur_stmt_list;
}

t2.c
----
typedef struct VEC_constructor_elt_gcx { } VEC_constructor_elt_gc;
#include "b.h"
struct gcc_target {
    void (* builtin_vec_perm) (tree*);
};
extern struct gcc_target targetm;
void dwarf2out_begin_prologue (tree t)
{
    (*targetm.builtin_vec_perm) (&t);
}
struct die_arg_entry_struct {
    tree arg;
};
void *gt_pch_p_20VEC_die_arg_entry_gc (struct die_arg_entry_struct *vec)
{
    return &(vec->arg);
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[pinskia at gmail dot com]

------- Comment #11 from pinskia at gmail dot com  2009-10-11 17:48 -------
Subject: Re:  bootstrap *using* lto fails

On Sun, Oct 11, 2009 at 8:13 AM, rguenth at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
> is this valid cross translation-unit if T is used across units?


Yes this is valid for C.  In C, types are across TUs are not based on
names.  This is why the code for -combine was complex with respect of
type equality.

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[espindola at google dot com]

------- Comment #12 from espindola at google dot com  2009-10-12 21:02 -------
(In reply to comment #9)
> Ok, so the issue here is that we have
> 
>   typedef struct VEC_constructor_elt_gc { } VEC_constructor_elt_gc;
> 
> vs.
> 
>   typedef struct VEC_constructor_elt_gcx { } VEC_constructor_elt_gc;
> 
> which causes us to not merge the two union tree_node types which are
> 
>   typedef union tree_node *tree;
>   union tree_node {
>     tree * use;
>     VEC_constructor_elt_gc *elts;
>   };
> 
> And in the end because we look through typedefs here:
> 
>   static hashval_t
>   iterative_hash_type_name (tree type, hashval_t v)
>   {
>     tree name = TYPE_NAME (TYPE_MAIN_VARIANT (type));
> 
> Now this is necessary - we'd want to merge
> 
>   union tree_node {
>     tree * use;
>     struct VEC_constructor_elt_gc *elts;
>   };
> 
> as well.
> 
> So - this cannot be fixed by type merging, but instead together with what
> we need to fix TBAA issues for non-merged types we have to try to cover
> these issues as well.

I am a bit confused why we cannot merge the types.

If using structural equality, "struct VEC_constructor_elt_gc" and "struct
VEC_constructor_elt_gcx" should be equivalent since they are both {}. With
these being equivalent, the two typedefs defining VEC_constructor_elt_gc are
equivalent and finally the two "union tree_node" also are.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[rguenther at suse dot de]

------- Comment #13 from rguenther at suse dot de  2009-10-12 21:03 -------
Subject: Re:  bootstrap *using* lto fails

On Mon, 12 Oct 2009, espindola at google dot com wrote:

> ------- Comment #12 from espindola at google dot com  2009-10-12 21:02 -------
> (In reply to comment #9)
> > Ok, so the issue here is that we have
> > 
> >   typedef struct VEC_constructor_elt_gc { } VEC_constructor_elt_gc;
> > 
> > vs.
> > 
> >   typedef struct VEC_constructor_elt_gcx { } VEC_constructor_elt_gc;
> > 
> > which causes us to not merge the two union tree_node types which are
> > 
> >   typedef union tree_node *tree;
> >   union tree_node {
> >     tree * use;
> >     VEC_constructor_elt_gc *elts;
> >   };
> > 
> > And in the end because we look through typedefs here:
> > 
> >   static hashval_t
> >   iterative_hash_type_name (tree type, hashval_t v)
> >   {
> >     tree name = TYPE_NAME (TYPE_MAIN_VARIANT (type));
> > 
> > Now this is necessary - we'd want to merge
> > 
> >   union tree_node {
> >     tree * use;
> >     struct VEC_constructor_elt_gc *elts;
> >   };
> > 
> > as well.
> > 
> > So - this cannot be fixed by type merging, but instead together with what
> > we need to fix TBAA issues for non-merged types we have to try to cover
> > these issues as well.
> 
> I am a bit confused why we cannot merge the types.
> 
> If using structural equality, "struct VEC_constructor_elt_gc" and "struct
> VEC_constructor_elt_gcx" should be equivalent since they are both {}. With
> these being equivalent, the two typedefs defining VEC_constructor_elt_gc are
> equivalent and finally the two "union tree_node" also are.

We're not really using structural equality.  I have patches to go
both ways (more structural equality and less), both cause some
regressions.  So I'm digging somewhat further for now.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2009-10-16 14:30 -------
This particular problem seems to be fixed.  I'll add a testcase.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598

[Bug lto/41598] bootstrap *using* lto fails

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2009-10-16 14:43 -------
Subject: Bug 41598

Author: rguenth
Date: Fri Oct 16 14:42:47 2009
New Revision: 152904

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152904
Log:
2009-10-16  Richard Guenther  <rguenther@suse.de>

        PR lto/41598
        * gcc.dg/lto/20091016-1_0.c: New testcase.
        * gcc.dg/lto/20091016-1_1.c: Likewise.
        * gcc.dg/lto/20091016-1_a.h: Likewise.

Added:
    trunk/gcc/testsuite/gcc.dg/lto/20091016-1_0.c
    trunk/gcc/testsuite/gcc.dg/lto/20091016-1_1.c
    trunk/gcc/testsuite/gcc.dg/lto/20091016-1_a.h
Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598