|
Notes |
|
|
|
Hi,
Does the same also occur with the asm_fast.gc grade on MinGW? Does the same occur on other
non-Windows 32-bit machines.
(If the problem is not restricted to MinGW then it's probably an issue to related to Peter's changes
for unboxed doubles, since that didn't go onto the 11.07 branch.) |
|
|
|
(0000423)
|
maclarty
|
|
2011-12-02 21:40
|
|
|
The problem does not occur with asm_fast.gc or 32bit Linux. I also compared the c file generated on Linux and Windows and there are no differences. Note that I used a different version of gcc on Linux (4.4.3). |
|
|
|
|
|
I have MinGW gcc 4.5.0 on my laptop so I will give that a try. We should try 4.6.1 on Linux or Mac OS X. |
|
|
|
|
|
It also occurs with gcc 4.5.0 on MinGW. |
|
|
|
|
-O[01] --common-struct works
-O1 --inline-simple causes both values to be printed incorrectly. |
|
|
|
(0000428)
|
maclarty
|
|
2011-12-03 11:59
|
|
I believe the cause of the problem is some incorrect assumptions about how struct fields are aligned. Consider the following C program:
#include <stdio.h>
struct t {
void *f1;
double f2;
};
int main() {
printf("%p\n", &((struct t*)0)->f2);
}
On MinGW this produces 8, but on 32 bit Linux it produces 4.
In the C code generated for bug.m there is the following struct:
struct bug_scalar_cell_group_1 {
MR_Box f1;
MR_Float f2;
};
Later on we use MR_hl_field to extract the float field. However MR_hl_field casts the struct to an array of pointers and then looks up element 1. That would look at offset 4, but on MinGW, the float field is at offset 8. |
|
|
|
(0000429)
|
|
wangp
|
|
2011-12-03 12:36
|
|
That'd be it, thanks.
See also bug 0000211 |
|
|
|
(0000435)
|
|
wangp
|
|
2011-12-09 10:25
|
|
|
bug.m (474) 2011-12-02 20:08