This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: struct-reorg optimization


Jan Hubicka <jh@suse.cz> wrote on 25/08/2007 12:57:55:

> >
> > >
> > >   name1 = get_type_name (type1);
> > >   name2 = get_type_name (type2);
> > >
> > >   if (name1 && name2 && !strcmp (name1, name2))
> > >     return true;
> > >
> > >   if (name1 && name2 && strcmp (name1, name2))
> > >     return false;
> > >
> > > What happens if the two units declare type with same name and
completely
> > > different layout and use it for different variables?
> > > (ie in completely legal way).  Will we every get into this matching
> > > predicate?

We are not getting here with the type names in this case, because we
are comparing TYPE_MAIN_VARIANTs, which keep no names.

> >
> > We have two corner cases here: structs with the same name and different
> > bodies,
> > and structs with same body and different names. So I think
theoretically
> > structs are equal if they have the same name and the same body. But we
cut
> > the name in many cases (like in TYPE_MAIN_VARIAN), so there is no good
> > solution
> > for now.
>
> Hmm, OK.  Will tricking same name to different structures cause
> miscompilations or somethign?

It looks like the error happens only if these types really conflict.

For example,  if str_t is defined differently in unit1.c
and unit2.c and there is a function foo (str_t) defined in unit2.c
and called from unit1.c, then compiler detects conflicting type
for foo () when running with -combine:

unit2.c:14: error: conflicting types for âfooâ
unit1.c:11: error: previous declaration of âfooâ was here

(I suppose it happens during building cgraph).
Otherwise they successfully coexist, i.e. each unit uses its own type.

Olga

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]