Mercury Bugs - mercury
View Issue Details
0000513mercuryBugpublic2020-07-15 20:162020-07-29 01:56
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformOSOS Version
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? a.m (481) 2020-07-15 20:16
c bug513.c (1,189) 2020-07-15 23:38

2020-07-15 22:38   
On my Mac, the test case works in hlc, but fails in none.gc.
2020-07-15 22:47   
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)
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.
2020-07-29 01:56   
Fix committed 2020 July 29.

Issue History
2020-07-15 20:16maokoNew Issue
2020-07-15 20:16maokoFile Added: a.m
2020-07-15 22:38zsNote Added: 0001094
2020-07-15 22:38zsAssigned To => zs
2020-07-15 22:38zsStatusnew => assigned
2020-07-15 22:47juliensfNote Added: 0001095
2020-07-15 23:38zsFile Added: bug513.c
2020-07-15 23:38zsNote Added: 0001096
2020-07-29 01:56zsStatusassigned => resolved
2020-07-29 01:56zsResolutionopen => fixed
2020-07-29 01:56zsNote Added: 0001100