occasionally the first hop of a block would try to rearrange its registers (due
to evicted throughs), resulting in the phi moves copying values into the wrong
registers.
Rename our getline() to get_line() to prevent a conflict with POSIX
getline() declared in stdio.h.
Remove dangerous call to gets(). OpenBSD does not have gets(), C99
deprecated it and C11 removed it.
Also change spelling "sheild" to "shield".
This fixes flt_arith2flt() when sizeof(arith) != 4, where arith is
long. When cemcom.ansi sees an expression like d + 1 (where d is some
double), it calls flt_arith2flt() to convert 1 to floating-point. On
machines where sizeof(arith) != 4, the code did n >>= 1 when n should
not have been changed. If n was 1, then n == 0 became true. This
caused the code to convert 1 or -1 to 0.0.
My fix assumes sizeof(arith) >= 8, so I can use n >> 32. Machines
with sizeof(arith) of 5 to 7 would need to do (uarith)n >> 32, where
uarith must be an unsigned integer type of same size as arith.
In startrek.c, the Enterprise can now dock with a starbase. The
compiler no longer translates s1 - 1 to s1 - 0.0 and s1 + 1 to s1 +
0.0, so the game now looks for starbases next to the Enterprise.
This undoes part of bfeb736, and returns to using DBL_MAX_EXP and
DBL_MIN_EXP from float.h.
Add a dependency on math/localmath.h and other local header files so
libc is rebuilt when those headers change.
This restores the correct values of DBL_MAX, DBL_MIN_EXP, and related
constants. This fixes some range checks within libc, causing
atof("-36e90") and atof("1.44e-288") to return the correct values.
It seems that someone wanted to build flt_arith with a compiler that
had long but not unsigned long. This required extra code to
accomplish unsigned right shift, unsigned division, and unsigned
comparison using the signed operations. Now that we use uint32_t, we
can simply use the unsigned operations and remove the ucmp() function.
We have similar code in mach/proto/fp/ and in
lang/cem/libcc.ansi/stdlib/ext_comp.c where we use the unsigned
operations.
Some long variables become uint32_t, and some masks with 0xFFFFFFFF
disappear because uint32_t has only 32 bits.
Update flt_arith.3 to show that mantissa uses uint32_t.
Provide a target to install modules/src/flt_arith/test.c as flt_test
so I can run the tests.
This seems to fix an error when flt_arith converts a literal
double-precision float to IEEE format. For example, 0.5 and 0.75 got
converted to slightly below their correct values.
My host gcc for amd64 has 64-bit long, but flt_arith needs only 32
bits. The code (at least flt_add.c) can make 32-bit overflows. Such
overflows would set the higher bits of a 64-bit long, which might
cause problems later.
I need to use uint32_t and not int32_t because the code still uses
long, and the sign extension from int32_t to long would cause
problems. The mantissa represents a value in [0, 2) that can't be
negative, so unsigned type is better. Also, signed overflow is
undefined behavior in C, so flt_add.c better make overflows with
uint32_t and not int32_t.
This commit doesn't touch lang/cem/libcc.ansi/stdlib/ext_fmt.h which
continues to use unsigned long for its mantissa fields.
