2024-07-18 08:23 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000513mercuryBugpublic2020-07-29 01:56
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
Product Version 
Target VersionFixed in Version 
Summary0000513: higher-order terms in freebsd bug.
DescriptionHigher-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.
TagsNo tags attached.
Attached Files
  • ? file icon a.m (481 bytes) 2020-07-15 20:16
  • c file icon bug513.c (1,189 bytes) 2020-07-15 23:38




zs (developer)

On my Mac, the test case works in hlc, but fails in none.gc.


juliensf (administrator)

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)


zs (developer)

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.


zs (developer)

Fix committed 2020 July 29.

-Issue History
Date Modified Username Field Change
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
+Issue History