Re: Another case of DCE deleting live code

[Diego Novillo <dnovillo at redhat dot com>]

On Mon, 2004-11-01 at 18:21, Richard Kenner wrote:

> C43214C ()
> {
>   typedef character c43214c__proc2__T3b[1 .. 4];
>   typedef <unnamed type> struct <unnamed type>;
>   integer D.410;
>   character[1 .. 4] * proc2GP222__b1.1;
>   character[5 .. 8] * proc2GP222__b1.0;
>   struct FRAME.c43214c * CHAIN.3;
>   character proc2GP222__b1[5 .. 8];
>   typedef character c43214c__proc2GP222__T2b[5 .. 8];
>   typedef <unnamed type> struct <unnamed type>;
>   typedef character c43214c__stb[5 .. 8];
>   typedef <unnamed type> struct <unnamed type>;
>   typedef c43214c__TstbP1___XDLU_5__8 c43214c__TstbP1___XDLU_5__8;
>   struct FRAME.c43214c FRAME.2;
> 
> <bb 0>:
>   #   FRAME.2_2 = V_MAY_DEF <FRAME.2_1>;
>   FRAME.2.proc2GP222__b1 = "ABCD";
>   CHAIN.3_3 = &FRAME.2;
>   proc2GP222__b1.0_4 = &CHAIN.3_3->proc2GP222__b1;
>   proc2GP222__b1.1_5 = (character[1 .. 4] *) proc2GP222__b1.0_4;
>   #   TMT.5_8 = V_MAY_DEF <TMT.5_7>;
>   D.410_6 = __builtin_memcmp ("ABCD", proc2GP222__b1.1_5, 4);
>   if (D.410_6 != 0) goto <L0>; else goto <L3>;
> 
> <L0>:;
>   #   VUSE <TMT.5_8>;
>   __gnat_rcheck_16 ("c43214c.adb", 12);
> 
> <L3>:;
>   return;
> }
> 
Looks like a bug in the type alias information we get from the front
end.  In this case, the points-to analyzer gets lost when the program
takes the address of a structure field, so it throws up its hands and
says "I don't know".

So, we turn around and use the type system to find conflicting types. 
Since the call to __builtin_memcmp dereferences pointer
proc2GP222__b1.1, we are interested in determining whether the types of
'TMT.5' (the pointer's memory tag) and 'FRAME.2' have conflicting alias
sets.

proc2GP225__b1.1, UID 3, character[1 .. 4] *, type memory tag: TMT.5
TMT.5, UID 6, character[1 .. 4], is addressable, is global, call
clobbered
FRAME.2, UID 0, struct FRAME.c43214c, is an alias tag, is addressable,
default def: FRAME.2_1

So, we are comparing the types 'character [1 .. 4]' and 'struct
FRAME.c43214c'.  This structure is declared by the compiler as:

struct FRAME.c43214c
{
   character proc2GP225__b1;
};

I don't know anything about Ada's type system, but I do know that
get_alias_set and alias_sets_conflict_p are telling the alias analyzer
that these two types do NOT have conflicting alias sets.

(gdb) ptu var
FRAME.2
(gdb) ptu tag
TMT.5
(gdb) p get_alias_set(var)
$7 = 3
(gdb) p get_alias_set(tag)
$8 = 4
(gdb) p alias_sets_conflict_p (3, 4)
$9 = 0

That is why the alias analyzer is not creating an alias relation between
these two variables.  The bug is either in Ada's type system or somebody
is taking the address of something that it shouldn't.

There's not much I can do about this.  Somebody is lying to the alias
analyzer about the types.


Diego.