This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/41598] bootstrap *using* lto fails
- From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 11 Oct 2009 15:13:42 -0000
- Subject: [Bug lto/41598] bootstrap *using* lto fails
- References: <bug-41598-16169@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla 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