[Ada] current ACATS failure analysis

[<guerby at acm dot org>]

I looked at one of the ACATS failure, and reduced the problem to:

procedure Z is
   X : Positive := 0;
begin
   null;
end Z;

The compiler core dumps in:

void
set_mem_attributes (ref, t, objectp)
     rtx ref;
     tree t;
     int objectp;
{
  HOST_WIDE_INT alias = MEM_ALIAS_SET (ref);
  tree decl = MEM_DECL (ref); /* BOOM */

called by

      if (GET_CODE (result) == MEM)
	{
	  /* Update so it looks like this is of the proper type.  */
	  set_mem_alias_set (result, 0);
	  set_mem_attributes (result, exp, 0); /* HERE */
	}

(gdb) p *ref
$6 = {code = REG, mode = QImode, jump = 0, call = 0, unchanging = 0, 
  volatil = 0, in_struct = 0, used = 0, integrated = 0, frame_related = 0, 
  fld = {{rtwint = 58, rtint = 58, rtuint = 58, 
      rtstr = 0x3a <Address 0x3a out of bounds>, rtx = 0x3a, rtvec = 0x3a, 
      rttype = MAX_MACHINE_MODE, rt_addr_diff_vec_flags = {min_align = 58, 
        base_after_vec = 0, min_after_vec = 0, max_after_vec = 0, 
        min_after_base = 0, max_after_base = 0, offset_unsigned = 0, 0, 
        scale = 0}, rt_cselib = 0x3a, rtbit = 0x3a, rttree = 0x3a, bb = 0x3a, 
      rtmem = 0x3a}}}
(gdb) bt
#0  0x08230bff in set_mem_attributes (ref=0x401921e0, t=0x4019d180, objectp=1)
    at ../../gcc/gcc/emit-rtl.c:1666
#1  0x0805e9a3 in gnat_expand_expr (exp=0x4019d180, target=0x401920b0, 
    tmode=QImode, modifier=EXPAND_NORMAL) at ../../../gcc/gcc/ada/misc.c:623
#2  0x08256ca9 in expand_expr (exp=0x4019d180, target=0x401920b0, 
    tmode=QImode, modifier=EXPAND_NORMAL) at ../../gcc/gcc/expr.c:7496
#3  0x0824b216 in store_expr (exp=0x4019d180, target=0x401920b0, want_value=0)
    at ../../gcc/gcc/expr.c:4191
#4  0x08249931 in expand_assignment (to=0x4019bf68, from=0x4019d180, 
    want_value=0, suggest_reg=0) at ../../gcc/gcc/expr.c:4002
#5  0x0834ac2f in expand_decl_init (decl=0x4019bf68)
    at ../../gcc/gcc/stmt.c:4146
#6  0x08063358 in create_var_decl (var_name=0x4019d198, asm_name=0x0, 
    type=0x4019bd24, var_init=0x4019d180, const_flag=0, public_flag=0, 
    extern_flag=0, static_flag=0, attr_list=0x0)
    at ../../../gcc/gcc/ada/utils.c:1365
#7  0x0804bfc6 in gnat_to_gnu_entity (gnat_entity=1392, gnu_expr=0x4019d180, 
    definition=1) at ../../../gcc/gcc/ada/einfo.h:1355
#8  0x08077f6f in tree_transform (gnat_node=1397)
    at ../../../gcc/gcc/ada/trans.c:819
#9  0x080712c6 in gnat_to_code (gnat_node=1397)
    at ../../../gcc/gcc/ada/trans.c:247
#10 0x0807b41e in process_decls (gnat_decls=-99999990, gnat_decls2=0, 
    gnat_end_list=0, pass1p=1, pass2p=1) at ../../../gcc/gcc/ada/trans.c:4201
#11 0x08077a55 in tree_transform (gnat_node=1362) at sinfo.h:441
#12 0x080712c6 in gnat_to_code (gnat_node=1362)
    at ../../../gcc/gcc/ada/trans.c:247
#13 0x08079aa8 in tree_transform (gnat_node=1355) at sinfo.h:809
#14 0x080712c6 in gnat_to_code (gnat_node=1355)
    at ../../../gcc/gcc/ada/trans.c:247
#15 0x0822020c in back_end__call_back_end (mode=back_end__generate_object)
    at ../../../gcc/gcc/ada/back_end.adb:110
#16 0x08220c23 in _ada_gnat1drv () at ../../../gcc/gcc/ada/gnat1drv.adb:558
#17 0x0805db7f in yyparse () at ../../../gcc/gcc/ada/misc.c:174
#18 0x083560b7 in compile_file (name=0xbffff994 "z.adb")
    at ../../gcc/gcc/toplev.c:2337
#19 0x0835a799 in toplev_main (argc=2, argv=0xbffff814)
    at ../../gcc/gcc/toplev.c:4951
#20 0x082215ab in main (argc=2, argv=0xbffff814) at ../../gcc/gcc/main.c:35
#21 0x400455b0 in __libc_start_main () from /lib/libc.so.6

After poking around, I guess the culprit is all expressions turned
statically by the expander into a [constraint_error]:

Source recreated from tree for Z (body)
---------------------------------------

procedure z is
   x : positive := [constraint_error];
begin
   null;
   return;
end z;

It looks like those flow to the backend and something is wrong with
them, may be some new stuff related to alias set is not set up
properly for those nodes by gigi.

Hope this helps, I'm not up to speed to GCC/GNAT debugging hooks to
get a clear picture of the various data to go past this yet.

-- 
Laurent Guerby <guerby@acm.org>