The _fields array is too short to account for the Jz constructor (two src values, each with a tag word and the potential to store a dst value, which in turn has a tag word and a data word), if I understand the memory management scheme correctly, and the generated code for an Out overwrites the data fields of the nested dst rather than the intended un-used fields (from the additional payload of the Jz constructor).
Two workarounds avoid this particular failure - either removing the Jz constructor or padding the Out constructor with an extra () member. However, after poking around the C backend a bit, and reviewing the generated code with these workarounds, I think something is awry with the calculated "max scan count" for types like this.
First, an apology: I've tried to reduce this example to the minimum which triggers the behavior, but it could probably be shrunk further.
I've got a program:
which produces the unexpected output:
I've tracked the source of the
-1
to the generated C for theOut
constructor:The
_fields
array is too short to account for theJz
constructor (twosrc
values, each with a tag word and the potential to store adst
value, which in turn has a tag word and a data word), if I understand the memory management scheme correctly, and the generated code for anOut
overwrites the data fields of the nesteddst
rather than the intended un-used fields (from the additional payload of theJz
constructor).Two workarounds avoid this particular failure - either removing the
Jz
constructor or padding theOut
constructor with an extra()
member. However, after poking around the C backend a bit, and reviewing the generated code with these workarounds, I think something is awry with the calculated "max scan count" for types like this.