struct pf_rule had a few counter_u64_t counters. Those couldn't be
usefully comminicated with userspace, so the fields were doubled up in
uint64_t u_* versions.
Now that we use struct pfctl_rule (i.e. a fully userspace version) we
can safely change the structure and remove this wart.
Reviewed by: glebius
MFC after: 4 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D29645
(cherry picked from commit ab5707a5cf)
Stop using the kernel's struct pf_rule, switch to libpfctl's pfctl_rule.
Now that we use nvlists to communicate with the kernel these structures
can be fully decoupled.
Reviewed by: glebius
MFC after: 4 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D29644
(cherry picked from commit e9eb09414a)
Build libnv as position independent code so we can use it from shared
libraries.
MFC after: 4 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D29561
(cherry picked from commit 0dd13c7743)
- Correct the type of the sysctl value.
- Initialize the oldsize parameter to cap_sysctlbyname()
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 44bbda649d)
This was added in b2ca2e50b9, and serves to provide an initial value
to the PMC, eliminating the need for a second syscall via pmc_set(3).
Reviewed by: gnn, 0mp (manpages)
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29885
(cherry picked from commit 50f6c13997)
Found in "Understanding and Detecting Disordered Error Handling with
Precise Function Pairing" by Qiushi Wu et al.
Reviewed by: imp, jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29896
(cherry picked from commit 3cfd08c1c7)
During device destruction it is possible that open() succeed, but
fdevname() return NULL, that can't be assigned to string variable.
Fix that by adding explicit NULL check.
Also while there switch from fdevname() to fdevname_r().
Sponsored by: iXsystems, Inc.
MFC after: 2 weeks
(cherry picked from commit e49d3eb403)
For some reason the ld128 log1pl() implementation is less accurate than
logl(), but does at least guarantee precision >= the ld80 implementation.
Mark log1p_accuracy_tests as XFAIL for ld128 and increase the log1p tolerance
to the ld80 equivalent in accuracy_tests to avoid losing test coverage for
the other functions.
PR: 253984
Reviewed By: ngie, dim
Differential Revision: https://reviews.freebsd.org/D29039
(cherry picked from commit 1ad83445fc)
This avoids build failures due to the clang 12 warning:
'#pragma FENV_ACCESS' is not supported on this target - ignored
Clang 12 currently emits this warning for all non-x86 architectures.
While this can result in incorrect code generation (e.g. on AArch64 some
exceptions are not raised as expected), this is a pre-existing issue and
we should not fail the build due to this warning.
Reviewed By: dim, emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29743
(cherry picked from commit 168234fa67)
The LLVM bug was fixed a long time ago and with D29076 this test actually
passes now.
Reviewed By: andrew
Differential Revision: https://reviews.freebsd.org/D29092
(cherry picked from commit dbb2d6f5e1)
If long double has more than 64 mantissa bits, using uint64_t to hold the
mantissa bits will truncate the value and result in test failures. To fix
this problem use __uint128_t since all platforms that have
__LDBL_MANT_DIG__ > 64 also have compiler support for 128-bit integers.
Reviewed By: rlibby
Differential Revision: https://reviews.freebsd.org/D29076
(cherry picked from commit ce88eb476b)
I only tested the WARNS=6 change on AArch64 and AMD64, but this file has
unused functions for architectures with LDBL_PREC == 53.
While touching this file change the LDBL_PREC == 53 checks to i386 checks.
The long double tests should only be disabled for i386 (due to the rather
odd rounding mode that it uses) not all architectures where long double
is the same as double.
PR: 205449
Fixes: 87d65c747a ("lib/msun: Allow building tests with WARNS=6")
Reported by: Jenkins
(cherry picked from commit 7f5693d053)
This warning is very rarely useful (inline is a hint and not mandatory).
This flag results in many warnings being printed when compiling C++
code that uses the standard library with GCC.
This flag was originally added in back in r94332 but the flag is a no-op
in Clang ("This diagnostic flag exists for GCC compatibility, and has no
effect in Clang"). Removing it should make the GCC build output slightly
more readable.
Reviewed By: jrtc27, imp
Differential Revision: https://reviews.freebsd.org/D29235
(cherry picked from commit c8c62548bf)
Output a hex dump of the current fenv and the expected value to allow
comparing them without having to resort to interactive use of GDB.
(cherry picked from commit 6ccdee8ab5)
Some CPUs (e.g. AArch64 QEMU) cannot trap on floating point exceptions and
therefore ignore the writes to the floating point control register inside
feenableexcept(). If no exceptions are enabled after
feenableexcept(FE_ALL_EXCEPT), we can assume that the CPU does not
support exceptions and we can then skip the test.
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D29095
(cherry picked from commit 2b9dbcd390)
Also print the mismatched values when numbers compare not equal.
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D29091
(cherry picked from commit b424e0038a)
These appears to have been resolved by compiling the test with -fno-builtin
and/or using a newer compiler.
PR: 208703
Reviewed By: ngie
Differential Revision: https://reviews.freebsd.org/D28884
(cherry picked from commit b358534ab1)
This provides better error messages that just an assertion failure and
also makes it easier to mark individual tests as XFAIL.
It was also helpful when coming up with D28786 and D28787.
Differential Revision: https://reviews.freebsd.org/D28798
(cherry picked from commit 133bc64507)
Apparently GCC only supports arithmetic expressions that use static
const variables in initializers starting with GCC8. To keep older
versions happy use a macro instead.
Fixes: 221622ec0c ("lib/msun: Avoid FE_INEXACT for x86 log2l/log10l")
Reported by: Jenkins
Reviewed By: imp
Differential Revision: https://reviews.freebsd.org/D29233
(cherry picked from commit 05eac56a04)
This fixes tests/lib/msun/logarithm_test after compiling the test with
-fno-builtin (D28577). Adding invln10_lo + invln10_10 results in
FE_INEXACT (for all inputs) and the same for the log2l invln2_lo + invln2_hi.
This patch avoids FE_INEXACT (for exact results such as 0) by defining a
constant and using that.
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D28786
(cherry picked from commit 221622ec0c)
This caused LDBL_MANT_DIG to not be defined and therefore the scalbnl
alias was not being emitted for double==long double platforms.
Fixes: 760b2ffc ("Update scalbn* functions to the musl versions")
Reported by: Jenkins
(cherry picked from commit f5542795b9)
The only diff compared to musl is a minor change to scalbnl() to replace
musl's union ldshape with union IEEEl2bits.
This fixes the scalbn tests on non-x86 (since x86 has an assembly version
that is used instead).
Musl commit messages:
commit 8c44a060243f04283ca68dad199aab90336141db
Author: Szabolcs Nagy <nsz@port70.net>
Date: Mon Apr 3 02:38:13 2017 +0200
fix scalbn when result is in the subnormal range
in nearest rounding mode scalbn could introduce double rounding error
when an intermediate value and the final result were both in the
subnormal range e.g.
scalbn(0x1.7ffffffffffffp-1, -1073)
returned 0x1p-1073 instead of 0x1p-1074, because the intermediate
computation got rounded to 0x1.8p-1023.
with the fix an intermediate value can only be in the subnormal range
if the final result is 0 which is correct even after double rounding.
(there still can be two roundings so signals may be raised twice, but
that's only observable with trapping exceptions which is not supported.)
commit 2eaed464e2080d8321d3903b71086a1ecfc4ee4a
Author: Szabolcs Nagy <nsz@port70.net>
Date: Wed Sep 4 15:52:54 2013 +0000
math: use float_t and double_t in scalbnf and scalbn
remove STRICT_ASSIGN (c99 semantics is assumed) and use the conventional
union to prepare the scaling factor (so libm.h is no longer needed)
commit 1b77b9072f374bd26eb0574b83a0d5f18d75ec60
Author: Szabolcs Nagy <nsz@port70.net>
Date: Thu Aug 15 10:07:46 2013 +0000
math: minor scalbn*.c simplification
commit c4359e01303da2755fe7e8033826b132eb3659b1
Author: Szabolcs Nagy <nsz@port70.net>
Date: Tue Nov 13 10:55:35 2012 +0100
math: excess precision fix modf, modff, scalbn, scalbnf
old code was correct only if the result was stored (without the
excess precision) or musl was compiled with -ffloat-store.
now we use STRICT_ASSIGN to work around the issue.
(see note 160 in c11 section 6.8.6.4)
commit 666271c105e4137bdfa195e217799d74143370d4
Author: Szabolcs Nagy <nsz@port70.net>
Date: Tue Nov 13 10:30:40 2012 +0100
math: fix scalbn and scalbnf on overflow/underflow
old code was correct only if the result was stored (without the
excess precision) or musl was compiled with -ffloat-store.
(see note 160 in n1570.pdf section 6.8.6.4)
commit 8051e08e10d2b739fcfcbc6bc7466e8d77fa49f1
Author: nsz <nsz@port70.net>
Date: Mon Mar 19 10:54:07 2012 +0100
simplify scalbn*.c implementations
The old scalbn.c was wrong and slow, the new one is just slow.
(scalbn(0x1p+1023,-2097) should give 0x1p-1074, but the old code gave 0)
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D28872
(cherry picked from commit 760b2ffc55)
I did this without a full vendor update since that would cause too many
conflicts. Since these files now almost match the NetBSD sources the
next git subtree merge should work just fine.
Reviewed By: lwhsu
Differential Revision: https://reviews.freebsd.org/D28797
(cherry picked from commit 1ec3feb648)
This tests fork()s, so if there is still data in the stdout buffer on fork
it will print it again in the child process. This was happening in the
CheriBSD CI and caused the test to complain about malformed TAP output.
Reviewed By: ngie
Differential Revision: https://reviews.freebsd.org/D28397
(cherry picked from commit 892a05ee3a)
Preserve more space for swap devise names.
Prevent line overflow with long devise name.
Don't draw a bar when swap is not used at all.
Simplify and optimize code.
Change the label to end at end of 100%.
PR: 251655
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D27496
(cherry picked from commit 8d06c3e7a4)
