|
Notes |
|
|
(0001094)
|
|
zs
|
|
2020-07-15 22:38
|
|
|
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) |
|
|
|
(0001096)
|
|
zs
|
|
2020-07-15 23:38
|
|
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. |
|
|
|
(0001100)
|
|
zs
|
|
2020-07-29 01:56
|
|
|
Fix committed 2020 July 29. |
|
a.m (481) 2020-07-15 20:16
bug513.c (1,189) 2020-07-15 23:38