|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000513||mercury||Bug||public||2020-07-15 20:16||2020-07-29 01:56|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000513: higher-order terms in freebsd bug.|
|Description||Higher-order terms with multi deterministic behave weirdly in FreeBSD. The attached code print weird number whereas normally it should print 5. I guess it print some random value on the stack.|
|Tags||No tags attached.|
|On my Mac, the test case works in hlc, but fails in none.gc.|
On my Linux system it fails (producing [take(0)]) on asm_fast.gc with the current rotd and 20.01.
(It does work with Mercuy 14.01.1.)
It also works with the MLDS backends in general (hlc.gc,java,csharp)
I have diagnosed the bug. It has nothing to do with higher order code or
solutions. The problem is caused by incorrect tracking of where N is stored.
The attached code is the code we generate for revert in LLDS grades.
Initially, as the first argument, N is in r1. Since N is needed in the second
disjunct but r1 may be overwritten in code executed after the if-then-else
before execution backtracks to the second disjunct, we save N in framevar 1,
and the second disjunct gets it from there.
The problem is that (a) the else case of the if-then-else also gets N from
framevar 1, but (b) the code for saving N in framevar 1 occurs *after* the
test N % 2 = 0, and since 5 % 2 != 0, it is never executed. So yes, maoko
was right: the value that the else case wraps up in take(), i.e. framevar 1,
*is* a random value on the stack.
|Fix committed 2020 July 29.|
|2020-07-15 20:16||maoko||New Issue|
|2020-07-15 20:16||maoko||File Added: a.m|
|2020-07-15 22:38||zs||Note Added: 0001094|
|2020-07-15 22:38||zs||Assigned To||=> zs|
|2020-07-15 22:38||zs||Status||new => assigned|
|2020-07-15 22:47||juliensf||Note Added: 0001095|
|2020-07-15 23:38||zs||File Added: bug513.c|
|2020-07-15 23:38||zs||Note Added: 0001096|
|2020-07-29 01:56||zs||Status||assigned => resolved|
|2020-07-29 01:56||zs||Resolution||open => fixed|
|2020-07-29 01:56||zs||Note Added: 0001100|