EXT_FRACBITS, the number of bits in the _binary encoding_ that stores
the trailing significand field, is never 113. In IEEE 754 binary128,
it is 112, even though there are 113 bits of precision in the set of
floating-point numbers -- the leading 1 bit is implicit in binary128.
So ld128 platforms like aarch64 and sparc64 were skipping the real
definition and just defining rintl as an alias for rint, which is
wrong.
In contrast, LDBL_MANT_DIG, the number of bits of precision in the set
of floating-point numbers (p, in IEEE 754 parlance), is 113 in IEEE 754
binary128. This is also the constant used in FreeBSD libm anyway. So
let's just use that instead of trying to translate it to our private
EXT_FRACBITS (not defined in FreeBSD) with a fencepos terror. And
delete the buggy rintl=rint alias.
PR lib/58054
Suggested by uwe@, in reaction to the previous commit, which preferred
octal in the examples. Hexadecimal escapes are more familiar to most
programmers, and the chance of mistaking \x14 for decimal 14 is less
than the chance of mistaking octal \014 for decimal 14.
Using hexadecimal character escapes requires separate string literals if
the description starts with one of the letters A-F; octal character
escapes have at most 3 digits, reducing ambiguity.
Use `printf` instead of `echo` for precise output
`man` pages generated under NetBSD and Linux differ as the escape codes
may or may not be interpreted when going through those two chained `echo`es.
Instead just use `printf`, which produces the desired output, always.
MAKELINKLIB that follows MKLINKLIB but can be overwritten by Makefiles
MAKESTATICLIB that follows MKSTATICLIB but can be overwritten by Makefiles
LINKINSTALL that follows MAKELINKLIB but can be overwritten by Makefiles
These give enough control to the module Makefiles so that they don't need
to override the default library install rules which break the debug sets.
- Remove /usr/libexec/named which duplicated /usr/lib/named
This is an attempt to diagnose why it's flaky in the releng testbeds
but not when I run it. This change will be backed out once we get
new testbed output.
If set, then when rump daemonizes, it opens the path in RUMP_STDOUT
and redirects fd 1 to that (which mostly gets the kernel console
output), and opens the path in RUMP_STDERR and redirects fd 2 to that
(no idea what this gets but it's probably good to record if it ever
gets anything).
This will allow tests that rely on rump_server daemons to stash the
output for diagnostics in case, e.g., the rump kernel crashes.
PR bin/58112
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
Otherwise, a pending signal may be delivered on the wrong stack when
we restore the signal mask.
While here:
- Tidy the code a little bit.
- Sprinkle comments to explain what's going on.
- Use `xorl %eXX,%eXX' instead of `xorq %rXX,%rXX'.
=> Same effect, one byte shorter, breaks dep chain on more uarches.
- Use forward branches for statically predicted not-taken.
=> val==0 is unlikely in longjmp
PR lib/57946
Lint had warned about the constant expression '0x03 << 30' but not about
the structurally equal nonconstant expression '(rnd_dir & 0x03) << 30'.
No binary change.
This doesn't make a semantic difference -- d can only take on the ten
values {0,1,2,3,4,5,6,7,8,9}, and the arithmetic with it later all
comes out the same whether the type is unsigned or time_t, even if
time_t were int32_t instead of int64_t.
But it pacifies overzealous compilers used by downstream users of
this code. And while it's silly to use a much wider type (64-bit
signed) than is needed here to store a single digit, it doesn't
really hurt either (32-bit unsigned is much larger than needed too).
PR lib/58041
riastradh