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.
unlink("core") doesn't work with OpenBSD, where core dumps have names
like "ncg.core". Users who don't want core dumps can turn them off
with "ulimit -c 0" in sh(1). Then the system doesn't write a core
dump. That's better than writing core then unlinking it.
This commit changes how ack(1) parses backslashes in its descr files.
Before this commit, ack set the high bit of each character escaped by
a backslash, and later cleared all high bits in command arguments, but
this lost the high bits in non-ASCII filenames. After this commit,
ack keeps backslashes in strings while processing them. Functions
scanvars(), scanexpr(), doassign(), unravel(), addargs() now
understand backslashes. I remove from ack_basename() the warning
about non-ASCII characters.
This commit makes some incompatible changes for backslashes in descr
files. None of our descr files uses backslashes, except for those
backslashes that continue lines, and there are no changes for those
backslashes. The problem with non-ASCII filenames had its cause in a
feature that we weren't using.
With this commit, ack now understands backslashes after the = sign in
both "var NAME=value" and "mapflag -flag NAME=value". Before, ack
never scanned backslashes in "var" lines, so "var A=\{B}" failed to
prevent expansion of B. Now it does. Before, ack did scan for
backslashes in the "-flag NAME=" part of "mapflag" lines. Now it
doesn't, so it is no longer possible to map a flag that contains a
literal space, tab, or star "*".
I removed the expansion of "{{" to "{". One can use "\{" for a
literal "{", and "\{" now works in "var" lines. Before and now, ack
never expanded "{" in flags for "mapflag", so the correct way to map a
literal flag "-{" remains "mapflag -{ ...", not "mapflag -{{ ...".
(The other way "mapflag -\{ ..." stops working with this commit.)
Backslashes in strange places, like "{NA\ME}", probably have different
behavior now.
Backslashes in "program" lines now work. Before, ack scanned for
backslashes there but forgot to clear the high bits later.
Escaping < or > as \< or \> now works, and prevents substitution of
the input or output file paths. Before, ack only expanded the first <
or > in each argument. Now, it expands every unescaped < or > in an
argument, but this is an accident of how I rewrote the code. I don't
suggest to put more than one each of < or > in a command. The code no
longer optimizes away its recursive calls when the argument is "<".
The code continues to set or clear the high bit NO_SCAN on the first
characters of flags. This doesn't seem to be a problem, because flags
usually begin with an ASCII hyphen '-'.
If fork() fails, then report a fatal error. Don't spin the cpu
retrying fork() until it succeeds. It can fail when we reach a limit
on the number of processes. Spinning on the cpu would slow down other
processes when we want them to exit. This would get bad if we had a
parallel build with multiple ack processes spinning.
new= newvar(name) takes ownership of the string and might free its
memory. Don't print name. Do print new->v_name.
Also #include <string.h> for strcmp().
Declare most functions before using them. I declare some functions in
ack.h and some in trans.h (because trans.h declares type trf). I
leave declarations of scanb() and scanvars() in .c files because they
need type growstring. (I can't #include "grows.h" in another header
file as long as grows.h doesn't guard against multiple inclusion.)
Functions used within one file become static. I remove a few tiny
functions. I move a few functions or declarations to more convenient
places. Some functions now return void instead of a garbage int.
I feel that keyword "register" is obsolete, so I removed it from where
I was editing. This commit doesn't touch mktables.c
Before this commit, the headers in plat/osx/include got installed
twice into PLATIND/osx386/include and PLATIND/osxppc/include. This
commit installs them once into PLATIND/osx/include and changes both
descr files to find them.
Several rules in lang/ depend on plat/osx386/include+headers or
plat/osxppc/include+headers. They each become a simplerule that
depends on plat/osx/include+headers.
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.
