#stage2 issues

1 messages · Page 1 of 1 (latest)

marble hare
#

My project works with -fstage1, though recently stage2 has advanced to the point where my project passes its unit tests without the flag. However, in trying to get my projects fuzz tests/benchmark working I'm running into some issues where I'm seeing really odd behavior from the binaries produced by stage 2. I'm noticing the stage 2 version is tripping some bounds checks and when I go into the code to try to add some debug prints, simply extracting out a value into a constant to try to inspect it changes the behavior of the code (the program then crashes in a different place than where I was trying to inspect). It seems pretty clear theres some memory corruption going on somewhere though Im not entirely sure where to begin looking?

c1 = options[p1.range(u8, 0, battle.choices(.P1, result.p1, &options))];
c2 = options[p2.range(u8, 0, battle.choices(.P2, result.p2, &options))];

->

const a = battle.choices(.P1, result.p1, &options);
c1 = options[p1.range(u8, 0, a)];
c2 = options[p2.range(u8, 0, battle.choices(.P2, result.p2, &options))];
marble hare
#

OK, so after much gnashing of teeth I found that if I pull the second call into a constant as well everything is hunky dory:

const a = battle.choices(.P1, result.p1, &options);
c1 = options[p1.range(u8, 0, a)];
const b = battle.choices(.P2, result.p2, &options);
c2 = options[p2.range(u8, 0, b)];

I think the problem is that the battle.choices function mutates options which is then indexed into... but somehow this results in garbage on stage 2. Is this expected (despite working on stage 1?), or is this a language bug?

#

(incidentally, stage2's (ReleaseFast, stripped) output seems to be about 1.07x slower for this particular benchmark than stage1's output)