On Tue, Apr 19, 2011 at 12:21 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Mon, Apr 18, 2011 at 11:45:03PM +0200, Eric Botcazou wrote:
>> 2011-04-18 Eric Botcazou <ebotca...@adacore.com>
>>
>> PR lto/48148
>> * gimple.c (gimple_types_compatible_p_1) <ENUMERAL_TYPE>: Do not
>> merge the types if they have different enumeration identifiers.
>
> While I think it is a step in the right direction, IMHO we can reach the
> same error if we merge say enums from:
> TU1.c:
> void foo (void)
> {
> enum A { B, C } e = B;
> bar ((int) e);
> }
> TU2.c:
> enum A { B, C } f;
> extern void baz (enum A);
> void test (void)
> {
> baz (0);
> }
> If enum A from second TU is merged with enum A from first TU, but DIE
> for it isn't needed in the partition containing TU2, then
> when trying for call site to add DIE for call to baz it needs to be emitted
> and it tries to emit it with the incorrect TYPE_CONTEXT.
Sure, but that problem applies to all types.
> IMHO types with incompatible TYPE_CONTEXT should never be compatible.
> Where incompatible TYPE_CONTEXT is something that needs some thought,
> if both TYPE_CONTEXTs are NULL / TRANSLATION_UNIT_DECL, it is
> fine to merge them, if it is a FUNCTION_DECL, it better be the same
> FUNCTION_DECL, if it is some type, it better be a gtc compatible type.
> TYPE_CONTEXT is IMHO relevant to all types, not just ENUMERAL_TYPE.
>
> Then, if we ever want to make LTO code actually debuggable, probably
> types with different TYPE_NAMEs shouldn't be considered to be compatible
> either, say enum A { B, C } a; in one TU and enum D { B, C } d; in another TU,
> otherwise ptype a or ptype d will be wrong.
Yeah, now that we merge the TYPE_CANONICAL web separately we
can do with a lot less "real" type merging without any effect on semantics.
We'll just pay with memory usage for better debug info.
Richard.
> Jakub
>
