1. Instead of calling out VAX by name, use #ifdef NAN.
2. Verify signbit works on long double on all architectures, not just
those with __HAVE_LONG_DOUBLE which means long double is _larger_
than double.
3. Minor formatting tidying.
Conversion from uint64_t to long double should work on all ports,
including those where long double is the same as double, i.e., where
__HAVE_LONG_DOUBLE is undefined.
Instead, conditionalize the test cases on how many bits of precision
long double has in the significand, according to LDBL_MANT_DIG. The
conditionals here should handle binary128, powerpc double-dekker
(~106-bit precision), x86 extended precision (80-bit), m68k extended
precision (80-bit), and VAX D (56-bit).
If long double is the same as double, i.e., __HAVE_LONG_DOUBLE is
undefined, these tests should still pass, since they don't rely on
extra precision beyond double.
long double and LDBL_EPSILON work even on architectures where long
double is the same as double, i.e., where the confusingly named
__HAVE_LONG_DOUBLE is not defined.
cosl should always be defined even on architectures where long double
is the same as double so the confusingly named __HAVE_LONG_DOUBLE is
not defined.
__HAVE_LONG_DOUBLE just means long double is different from double.
This test should always pass on all ports, even if long double is the
same as double; it doesn't test any additional precision.
Normally I don't like CHECK(A && B) and favour CHECK(A); CHECK(B)
instead, so you can see which one failed, but in this case the inputs
are displayed anyway so we don't lose anything unless the
floating-point printer is broken.
1. Exercise more edge cases around the largest exponent that can
represent non-integers.
2. - Verify modf can handle all cases modff can.
- Veriy modf can handle some cases modff can't.
- Verify modfl can handle all cases modf or modff can.
- If long double isn't just double, verify modfl can handle some
cases modf and modff can't.
3. Check infinities and NaN.
4. Verify oddness, i.e., modf(-x) = -modf(x).
5. Display more useful diagnostics in case any of this goes wrong.
All changes to the global variable 'dcs' are tracked now, to help
identify the cause of the failing tests in expr_sizeof and
gcc_attribute_aligned.
While here, test more invalid type combinations in typedefs.
Even though the test only uses fixed-size types, lint's computed size of
the resulting struct differs between i386 (80) and x86_64 (112). Both
are wrong, probably due to the unrelated struct declaration above, as
already mentioned in the comments.
integers (10^50 or so), so we don't exceed the capacity of systems where
long int is only 32 bits.
Hopefully will unbreak the i386 build, perhaps others.
This uses inputs that can't be distinguished with only 53 bits of
precision, so it should work in essentially all long double formats
to detect when nearbyintl is incorrectly implemented in terms of
nearbyint.
PR lib/58054
The macro 'offsetof(t, m)' already expanded to a constant expression for
scalar members but not for arrays. This was because the macro expanded
to '(size_t)(((t *)0)->m)', which lint internally represents as
'addr(indir(ptr(0) + offset(m)))', and build_address simplifies
'addr(indir(x))' to 'x' if the types match. The types only match for
scalar types though, but not for arrays.
When build_address happens, the type information is incomplete,
therefore 'offsetof(t, array)' has to be simplified at a later point.
This test is skipped in most circumstances because it creates a file
whose apparent size is 4.5 GB. It's an ISO 9660 image though,
containing mostly null bytes. Nevertheless, tmpfs doesn't allow such a
big file to be created, so this test is skipped in settings where /tmp
is on a tmpfs.
If the test is run, the ISO image is uncompressed, which takes several
minutes. Replace bzip2 with direct file creation from a hex dump of
that disk image, which is easier to inspect manually and also faster by
about 3 magnitudes.
Multiple arguments to atf_set are joined by spaces, there's no need for
an extra space.
The exit status on success must be 0, so don't ignore it.
Remove the unnecessary shell wrapper, as no redirection is going on.
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.
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.
This is not very tidy at the moment, but it's an experiment using the
approach in PR bin/58112, to diagnose why t_sp:sigsafe keeps failing
intermittently. If this works, perhaps can tidy it up and apply it
to all the other tests that run rump_servers.
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
1. For tools that use elftoolchain: always use elftoolchain's
elfdefinitions.h. Don't even think about looking at the host's
sys/exec_elf.h, which makes no sense and should never happen.
(ELF tools that don't use elftoolchain, like m68k-elf2coff,
continue to use nbincludes/sys/exec_elf.h. But no more nbincludes
hacks in elftoolchain.)
2. For kernel components (solaris, zfs, dtrace): always use
sys/exec_elf.h, even in Solaris components via sys/elf.h.
elfdefinitions.h is not wired up in the kernel build at all.
3. For most userland components that involve libelf: use
elfdefinitions.h via libelf header files (libelf.h, gelf.h).
libdtrace in particular requires _all_ R_* reloc type definitions,
but sys/exec_elf.h brings in only the _current machine's_ R_*
reloc type definitions. (While here: Use uintptr_t instead of
Elf_Addr for pointer-to-integer cast, since Elf_Addr is MD and
provided only by sys/exec_elf.h, not by elfdefinitions.h.)
And most userland components using libelf don't rely on any
properties of the current machine from sys/exec_elf.h, so they can
use libelf's elfdefinition.h.
Exceptions:
- dtrace drti.c relies on link.h -> link_elf.h -> sys/exec_elf.h,
but it also relies on sys/dtrace.h -> sys/elf.h ->
elfdefinitions.h like other userland components using sys/elf.h.
- kdump-ioctl.c uses sys/exec_elf.h directly and sys/dtrace.h ->
sys/elf.h -> elfdefinitions like other userland components using
sys/elf.h.
- t_ptrace_wait.c (via t_ptrace_core_wait.h) uses libelf to parse
core files, but relies on sys/exec_elf.h for struct
netbsd_elfcore_procinfo.
None of these exceptions needs all R_* reloc type definitions, so
as a workaround, we can just suppress libelf's elfdefinitions.h by
defining _SYS_ELFDEFINITIONS_H_ and use sys/exec_elf.h in these
exceptions.
And undo the whole BUILTIN_ELF_HEADERS mistake. This was:
- half bogus workarounds for missing build_install dependencies in
tools/Makefile, which are no longer missing now, and
- half futile attempt to use src/sys/sys/exec_elf.h via nbincludes in
tools involving libelf instead of libelf's elfdefinitions.h, which
collides.
Longer-term, we may wish to unify sys/exec_elf.h and libelf's
elfdefinitions.h, so we don't have to play these games.
But at least now the games are limited to three .c files (one of
which is generated by Makefile.ioctl-c), rather than haphazardly
applied tree-wide by monstrous kludges in widely used .h files with
broken hackarounds to get the tools build lurching to completion.
The C standards do not specify a fixed type for an array subscript, it
just has to be an integer type. Previously, query 4 fired for the
ubiquitous expression 'ptr[sz]' when sz had type 'size_t'.
The test platform_ilp32_long is unaffected by this change, as the
integer constant 0x80000000 has type 'unsigned int', while size_t is
'unsigned long' on those platforms, and even though the types 'unsigned
int' and 'unsigned long' have the same value space, there's still a
conversion, at least for now.
Unfortunately, we can't quite use strptime as a black box to detect
the cases that triggered undefined behaviour, because strptime just
fails in that case anyway since the number that would go in .tm_year
is far out of the representable range.
PR lib/58041
Previously, an unsigned operation that had a negative result went
undetected in a few cases. Now, all results that are not representable
by their type are considered overflows.
The implementation of signed shift-right had been wrong for a few
commits.
martin