Re: [patch] Fix PR lto/48148

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Apr 18, 2011 at 11:45:03PM +0200, Eric Botcazou wrote:
> 2011-04-18  Eric Botcazou  <ebotcazou@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.

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.

	Jakub