[m-dev.] accurate GC stack layout bug

[Fergus Henderson]

Building in grade asm_fast.agc (& no other special options) results in
code for library/rational.m which appears to have an invalid stack layout
for one of the procedures.  This causes the accurate collector to crash.

Zoltan, would you mind having a look at this one?

The procedure in question is rational.norm/2, and the specific label is
mercury__fn__rational__rational_norm_2_0_i20.  The generated code
clearly has both MR_stackvar(5) and MR_stackvar(1) live, with the former
containing the succip and the latter holding a value of type "integer".
But the generated stack layout structure only records the former,
not the latter.

The generated code is
 ...
 |         MR_stackvar(1) = MR_r1;
 |         MR_r1 = MR_stackvar(4);
 |         MR_call_localret(MR_ENTRY(mercury__integer__big_quot_rem_4_0),
 |                 mercury__fn__rational__rational_norm_2_0_i20,
 |                 MR_ENTRY(mercury__fn__rational__rational_norm_2_0));
 | MR_define_label(mercury__fn__rational__rational_norm_2_0_i20);
 |         MR_update_prof_current_proc(MR_LABEL(mercury__fn__rational__rational_nor
 | m_2_0));
 |         MR_tag_offset_incr_hp_msg(MR_r2, MR_mktag(0), 0, (MR_Integer) 2, mercury
 | __fn__rational__rational_norm_2_0, "rational.rational/0");
 |         MR_field(MR_mktag(0), MR_r2, (MR_Integer) 0) = MR_stackvar(1);
 |         MR_field(MR_mktag(0), MR_r2, (MR_Integer) 1) = MR_r1;
 |         MR_r1 = MR_r2;
 |         MR_succip = (MR_Code *) MR_stackvar(5);
 |         MR_decr_sp_pop_msg(5);
 |         MR_proceed();
 | MR_END_MODULE

and the generated stack layout structure is

 | static const MR_Label_Layout mercury_data__label_layout__mercury__fn__rational__
 | rational_norm_2_0_i20 = {
 |         (const MR_Proc_Layout *)
 |                 &mercury_data__proc_layout__mercury__fn__rational__rational_norm
 | _2_0,
 |         MR_PORT_EXCEPTION,
 |         MR_FALSE,
 |         0,
 |         1,
 |         (const void *)
 |                 (MR_Word *) &mercury_data_rational__common_39,
 |         (const MR_uint_least16_t *)
 |                 (MR_Integer) 0,
 |         (const MR_Type_Param_Locns *)
 |                 (MR_Integer) 0
 | };

Note that the "1" there is the number of variables. 
The definition of mercury_data_rational__common_39 is

 | static const struct mercury_data_rational__common_type_8
 |         mercury_data_rational__common_39 =
 | {
 |         (MR_Word *) &mercury_data_builtin__type_ctor_info_succip_0,
 |         (MR_uint_least8_t) (MR_Integer) 21
 | };

which is OK for one variable (the 21 is 5<<2 + 1, which encodes det
stack slot number 5).  As you can see, there is no entry for the
integer stored in MR_stackvar(1).

This is a Heisenbug: if you compile with any `-d' (--dump-hlds) option,
the generated code changes, and the bug goes away.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------