This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GIMPLE types merging in LTO compiler
On Fri, May 14, 2010 at 9:33 PM, Eric Botcazou <ebotcazou@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).
Richard.
> --
> Eric Botcazou
>