| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000513 | mercury | Bug | public | 2020-07-15 20:16 | 2020-07-29 01:56 | ||||
| Reporter | maoko | ||||||||
| Assigned To | zs | ||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | |||||||||
| 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. | ||||||||
| Attached Files | |||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
zs (developer) 2020-07-15 22:38 |
On my Mac, the test case works in hlc, but fails in none.gc. |
|
juliensf (administrator) 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) |
|
zs (developer) 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. |
|
zs (developer) 2020-07-29 01:56 |
Fix committed 2020 July 29. |
| Notes |
| 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 |