i've been looking at the program below, which calculates
some bad values on arm and amd64 and thus crashes.
(i added an a few asserts to make the crashes more reliable.)
386 does not have this issue.
#include <u.h>
#include <libc.h>
#include <stdio.h>
void
main(void)
{
printf("%10.4lf\n", 9306112.0000);
exits("");
}
the "problem" boils down to this
#include <u.h>
#include <libc.h>
#define fpword0(x) ((FPdbleword*)&x)->hi
#define Exp_11 0x3ff00000
#define Frac_mask1 0xfffff
void
badcalc(double d)
{
double d2;
d2 = d;
fpword0(d2) &= Frac_mask1;
fpword0(d2) |= Exp_11;
print("%g %g\n", d, d2);
}
void
main(void)
{
badcalc(9306112.0000);
exits("");
}
so the question is, is the compiler free to assume that
d2 has not been modified? (it does not do this if uvlong
is subsituted)
- erik
---
; 5c -S fh.c
TEXT badcalc+0(SB),0,$28
MOVD d+0(FP),F3
MOVW d2-4(SP),R3
AND $1048575,R3
MOVW R3,d2-4(SP)
MOVW d2-4(SP),R1
ORR $1072693248,R1
MOVW R1,d2-4(SP)
MOVW $.string<>+0(SB),R0
MOVD F3,8(R13)
MOVD F3,16(R13)
BL ,print+0(SB)
RET ,
TEXT main+0(SB),0,$8
MOVD $9.30611200000000000e+06,F0
MOVD F0,4(R13)
BL ,badcalc+0(SB)
DATA .string<>+0(SB)/8,$"%g %g\n\z\z"
MOVW $.string<>+7(SB),R0
BL ,exits+0(SB)
RET ,
GLOBL .string<>+0(SB),$8
END ,
