> On Fri, May 14, 2010 at 9:33 PM, Eric Botcazou <ebotca...@adacore.com> wrote: > >> Ugh. This presents a chicken-and-egg problem to symbol resolution > >> and type-merging. > >> > >> To be clear, the issue is sth like > >> > >> unit1 > >> ----- > >> int size; > >> int a[size]; > >> > >> unit2 > >> ------ > >> extern int size; > >> extern a[size]; > >> > >> ? And you get the a's merged but a diagnostic about mismatched types? > > > > Yes, exactly. > > > >> One way to fix this would be to simply detect the situation and never > >> issue a diagnostic. Another way would be to delay the diagnostics > >> until after all types and symbols are merged. The natural place > >> for this would be lto_symtab_merge_cgraph_nodes () which already > >> is after type merging and still has all candidates available. > > > > Is suppressing the diagnostic sufficient? Will the two types be merged > > after > > the symbols are unified, or does that not matter at all? > > The types will not be unified. We are currently inserting VIEW_CONVERT_EXPRs > to make the IL type verification happy, but in the end it will cause > broken type-based alias info and thus may trigger miscompiles. I am in > the process of fixing both pieces (avoid the V_C_E by using MEM_REF > and avoid the miscompile by separating TBAA types from the IL types).
Also while working on this, please keep in mind that for data layout optimization we desperately need to have all accesses to the same memory object to have same type so we can rewrite it. ipa-struct-reorg is currently doing some pretty lame type combining based on type names for --combine, but we need sane framework for this. Honza
