Re: PF synproxy 12 seems to work now
On Sun, 15 Jul 2018 05:09:12 +0200, Lars Schotte wrote: > > PF synproxy seems to work now on 12. > It would be nice to move those changes to 11-stable, because there it > is still broken. Just saying. Are you talking about the following changes? https://lists.freebsd.org/pipermail/svn-src-all/2018-July/167217.html https://lists.freebsd.org/pipermail/svn-src-all/2018-July/167219.html They are marked "MFC after: 1 week", so they should appear in stable/11 soon. -- Herbert ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: local_unbound segfaults at boot
On Sun, 15 Jul 2018 03:19:11 +0200, Lars Schotte wrote: > > I see segfaulting too: > > FreeBSD wasp.2km.casa 12.0-CURRENT FreeBSD 12.0-CURRENT #6 r336229: Fri Jul > 13 01:51:31 CEST 2018 > r...@wasp.2km.casa:/usr/obj/usr/src/amd64.amd64/sys/GUSTIK amd64 > # service local_unbound restart > local_unbound not running? (check /var/run/local_unbound.pid). > Starting local_unbound. > Segmentation fault (core dumped) > /etc/rc.d/local_unbound: WARNING: failed to start local_unbound > > # du -sh unbound.core > 23Munbound.core unbound binaries were renamed to local-unbound. https://svnweb.freebsd.org/base?view=revision&revision=333573 # ls -l /usr/sbin/*unbound* -r-xr-xr-x 1 root wheel 150416 Jul 10 16:17 /usr/sbin/local-unbound -r-xr-xr-x 1 root wheel 47944 Jul 10 16:17 /usr/sbin/local-unbound-anchor -r-xr-xr-x 1 root wheel 35608 Jul 10 16:17 /usr/sbin/local-unbound-checkconf -r-xr-xr-x 1 root wheel 39736 Jul 10 16:17 /usr/sbin/local-unbound-control -r-xr-xr-x 1 root wheel 11030 Jul 10 16:17 /usr/sbin/local-unbound-setup Did you forget to run mergemaster, 'make delete-old' and 'make delete-old-libs' after the upgrade? -- Herbert ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
emulators/virtualbox-ose-additions-nox11 fails to build in poudriere-devel for amd64 context: fails CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE)
The failure: kBuild: Compiling VBoxGuestR0Lib - /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/Additions/common/VBoxGuest/lib/VBoxGuestR0LibPhysHeap.cpp In file included from /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/GuestHost/HGSMI/HGSMIMemAlloc.cpp:55: In file included from /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/HGSMIMemAlloc.h:31: In file included from /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/HGSMIDefs.h:35: In file included from /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/VBoxVideoIPRT.h:32: In file included from /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/iprt/string.h:45: In file included from /usr/src/sys/sys/libkern.h:41: In file included from /usr/src/sys/sys/systm.h:112: /usr/src/sys/sys/pcpu.h:207:1: error: static_assert failed "compile-time assertion failed" CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE); ^~~~ /usr/src/sys/sys/systm.h:107:21: note: expanded from macro 'CTASSERT' #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") ^ ~ (There are other example places that fail the same assert condition.) There is also a warning for PAGE_SIZE being redefined: In file included from /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/Additions/common/VBoxGuest/lib/VBoxGuestR0LibInit.cpp:33: In file included from /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/iprt/string.h:45: In file included from /usr/src/sys/sys/libkern.h:41: In file included from /usr/src/sys/sys/systm.h:111: In file included from /usr/src/sys/sys/param.h:141: /usr/include/machine/param.h:101:9: warning: 'PAGE_SIZE' macro redefined [-Wmacro-redefined] #define PAGE_SIZE (1
[PATCH] Recent libm additions
Apparently, the recents additions to libm were not
subject to any code review. The following patch
does two things. First, it works around
https://bugs.llvm.org/show_bug.cgi?id=8532
Second, it removes the pollution of libm with the
polevll.c functions. Those functions are used
only in ld80/e_powl.c, and those functions should
be inlined.
Index: Makefile
===
--- Makefile(revision 336304)
+++ Makefile(working copy)
@@ -56,7 +56,6 @@
imprecise.c \
k_cos.c k_cosf.c k_exp.c k_expf.c k_rem_pio2.c k_sin.c k_sinf.c \
k_tan.c k_tanf.c \
- polevll.c \
s_asinh.c s_asinhf.c s_atan.c s_atanf.c s_carg.c s_cargf.c s_cargl.c \
s_cbrt.c s_cbrtf.c s_ceil.c s_ceilf.c s_clog.c s_clogf.c \
s_copysign.c s_copysignf.c s_cos.c s_cosf.c \
Index: ld80/e_powl.c
===
--- ld80/e_powl.c (revision 336304)
+++ ld80/e_powl.c (working copy)
@@ -77,6 +77,7 @@
#include
#include "math_private.h"
+#include "polevll.c"
/* Table size */
#define NXT 32
Index: src/math_private.h
===
--- src/math_private.h (revision 336304)
+++ src/math_private.h (working copy)
@@ -828,7 +828,4 @@
long double __kernel_cosl(long double, long double);
long double __kernel_tanl(long double, long double, int);
-long double __p1evll(long double, void *, int);
-long double __polevll(long double, void *, int);
-
#endif /* !_MATH_PRIVATE_H_ */
Index: src/polevll.c
===
--- src/polevll.c (revision 336304)
+++ src/polevll.c (working copy)
@@ -69,7 +69,7 @@
* Polynomial evaluator:
* P[0] x^n + P[1] x^(n-1) + ... + P[n]
*/
-long double
+static inline long double
__polevll(long double x, void *PP, int n)
{
long double y;
@@ -88,7 +88,7 @@
* Polynomial evaluator:
* x^n + P[0] x^(n-1) + P[1] x^(n-2) + ... + P[n]
*/
-long double
+static inline long double
__p1evll(long double x, void *PP, int n)
{
long double y;
Index: src/s_cpow.c
===
--- src/s_cpow.c(revision 336304)
+++ src/s_cpow.c(working copy)
@@ -60,7 +60,7 @@
y = cimag (z);
absa = cabs (a);
if (absa == 0.0) {
- return (0.0 + 0.0 * I);
+ return (CMPLX(0.0, 0.0));
}
arga = carg (a);
r = pow (absa, x);
@@ -69,6 +69,6 @@
r = r * exp (-y * arga);
theta = theta + y * log (absa);
}
- w = r * cos (theta) + (r * sin (theta)) * I;
+ w = CMPLX(r * cos (theta), r * sin (theta));
return (w);
}
Index: src/s_cpowf.c
===
--- src/s_cpowf.c (revision 336304)
+++ src/s_cpowf.c (working copy)
@@ -59,7 +59,7 @@
y = cimagf(z);
absa = cabsf (a);
if (absa == 0.0f) {
- return (0.0f + 0.0f * I);
+ return (CMPLXF(0.0f, 0.0f));
}
arga = cargf (a);
r = powf (absa, x);
@@ -68,6 +68,6 @@
r = r * expf (-y * arga);
theta = theta + y * logf (absa);
}
- w = r * cosf (theta) + (r * sinf (theta)) * I;
+ w = CMPLXF(r * cosf (theta), r * sinf (theta));
return (w);
}
Index: src/s_cpowl.c
===
--- src/s_cpowl.c (revision 336304)
+++ src/s_cpowl.c (working copy)
@@ -59,7 +59,7 @@
y = cimagl(z);
absa = cabsl(a);
if (absa == 0.0L) {
- return (0.0L + 0.0L * I);
+ return (CMPLXL(0.0L, 0.0L));
}
arga = cargl(a);
r = powl(absa, x);
@@ -68,6 +68,6 @@
r = r * expl(-y * arga);
theta = theta + y * logl(absa);
}
- w = r * cosl(theta) + (r * sinl(theta)) * I;
+ w = CMPLXL(r * cosl(theta), r * sinl(theta));
return (w);
}
--
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
These changes look perfect to me.
Warner
On Sun, Jul 15, 2018, 9:08 AM Steve Kargl
wrote:
> Apparently, the recents additions to libm were not
> subject to any code review. The following patch
> does two things. First, it works around
>
> https://bugs.llvm.org/show_bug.cgi?id=8532
>
> Second, it removes the pollution of libm with the
> polevll.c functions. Those functions are used
> only in ld80/e_powl.c, and those functions should
> be inlined.
>
> Index: Makefile
> ===
> --- Makefile(revision 336304)
> +++ Makefile(working copy)
> @@ -56,7 +56,6 @@
> imprecise.c \
> k_cos.c k_cosf.c k_exp.c k_expf.c k_rem_pio2.c k_sin.c k_sinf.c \
> k_tan.c k_tanf.c \
> - polevll.c \
> s_asinh.c s_asinhf.c s_atan.c s_atanf.c s_carg.c s_cargf.c
> s_cargl.c \
> s_cbrt.c s_cbrtf.c s_ceil.c s_ceilf.c s_clog.c s_clogf.c \
> s_copysign.c s_copysignf.c s_cos.c s_cosf.c \
> Index: ld80/e_powl.c
> ===
> --- ld80/e_powl.c (revision 336304)
> +++ ld80/e_powl.c (working copy)
> @@ -77,6 +77,7 @@
> #include
>
> #include "math_private.h"
> +#include "polevll.c"
>
> /* Table size */
> #define NXT 32
> Index: src/math_private.h
> ===
> --- src/math_private.h (revision 336304)
> +++ src/math_private.h (working copy)
> @@ -828,7 +828,4 @@
> long double __kernel_cosl(long double, long double);
> long double __kernel_tanl(long double, long double, int);
>
> -long double __p1evll(long double, void *, int);
> -long double __polevll(long double, void *, int);
> -
> #endif /* !_MATH_PRIVATE_H_ */
> Index: src/polevll.c
> ===
> --- src/polevll.c (revision 336304)
> +++ src/polevll.c (working copy)
> @@ -69,7 +69,7 @@
> * Polynomial evaluator:
> * P[0] x^n + P[1] x^(n-1) + ... + P[n]
> */
> -long double
> +static inline long double
> __polevll(long double x, void *PP, int n)
> {
> long double y;
> @@ -88,7 +88,7 @@
> * Polynomial evaluator:
> * x^n + P[0] x^(n-1) + P[1] x^(n-2) + ... + P[n]
> */
> -long double
> +static inline long double
> __p1evll(long double x, void *PP, int n)
> {
> long double y;
> Index: src/s_cpow.c
> ===
> --- src/s_cpow.c(revision 336304)
> +++ src/s_cpow.c(working copy)
> @@ -60,7 +60,7 @@
> y = cimag (z);
> absa = cabs (a);
> if (absa == 0.0) {
> - return (0.0 + 0.0 * I);
> + return (CMPLX(0.0, 0.0));
> }
> arga = carg (a);
> r = pow (absa, x);
> @@ -69,6 +69,6 @@
> r = r * exp (-y * arga);
> theta = theta + y * log (absa);
> }
> - w = r * cos (theta) + (r * sin (theta)) * I;
> + w = CMPLX(r * cos (theta), r * sin (theta));
> return (w);
> }
> Index: src/s_cpowf.c
> ===
> --- src/s_cpowf.c (revision 336304)
> +++ src/s_cpowf.c (working copy)
> @@ -59,7 +59,7 @@
> y = cimagf(z);
> absa = cabsf (a);
> if (absa == 0.0f) {
> - return (0.0f + 0.0f * I);
> + return (CMPLXF(0.0f, 0.0f));
> }
> arga = cargf (a);
> r = powf (absa, x);
> @@ -68,6 +68,6 @@
> r = r * expf (-y * arga);
> theta = theta + y * logf (absa);
> }
> - w = r * cosf (theta) + (r * sinf (theta)) * I;
> + w = CMPLXF(r * cosf (theta), r * sinf (theta));
> return (w);
> }
> Index: src/s_cpowl.c
> ===
> --- src/s_cpowl.c (revision 336304)
> +++ src/s_cpowl.c (working copy)
> @@ -59,7 +59,7 @@
> y = cimagl(z);
> absa = cabsl(a);
> if (absa == 0.0L) {
> - return (0.0L + 0.0L * I);
> + return (CMPLXL(0.0L, 0.0L));
> }
> arga = cargl(a);
> r = powl(absa, x);
> @@ -68,6 +68,6 @@
> r = r * expl(-y * arga);
> theta = theta + y * logl(absa);
> }
> - w = r * cosl(theta) + (r * sinl(theta)) * I;
> + w = CMPLXL(r * cosl(theta), r * sinl(theta));
> return (w);
> }
>
> --
> Steve
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: emulators/virtualbox-ose-additions-nox11 fails to build in poudriere-devel for amd64 context: fails CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE)
[The build got to emulators/virtualbox-ose-additions and it also failed this way. The PAGE_SIZE warning did not occur. More notes added after the quoted history.] On 2018-Jul-15, at 7:49 AM, Mark Millard wrote: > The failure: > > kBuild: Compiling VBoxGuestR0Lib - > /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/Additions/common/VBoxGuest/lib/VBoxGuestR0LibPhysHeap.cpp > In file included from > /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/GuestHost/HGSMI/HGSMIMemAlloc.cpp:55: > In file included from > /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/HGSMIMemAlloc.h:31: > In file included from > /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/HGSMIDefs.h:35: > In file included from > /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/VBox/Graphics/VBoxVideoIPRT.h:32: > In file included from > /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/iprt/string.h:45: > In file included from /usr/src/sys/sys/libkern.h:41: > In file included from /usr/src/sys/sys/systm.h:112: > /usr/src/sys/sys/pcpu.h:207:1: error: static_assert failed "compile-time > assertion failed" > CTASSERT(sizeof(struct pcpu) == UMA_PCPU_ALLOC_SIZE); > ^~~~ > /usr/src/sys/sys/systm.h:107:21: note: expanded from macro 'CTASSERT' > #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") >^ ~ > > (There are other example places that fail the same assert condition.) > > There is also a warning for PAGE_SIZE being redefined: > > In file included from > /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/src/VBox/Additions/common/VBoxGuest/lib/VBoxGuestR0LibInit.cpp:33: > In file included from > /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/iprt/string.h:45: > In file included from /usr/src/sys/sys/libkern.h:41: > In file included from /usr/src/sys/sys/systm.h:111: > In file included from /usr/src/sys/sys/param.h:141: > /usr/include/machine/param.h:101:9: warning: 'PAGE_SIZE' macro redefined > [-Wmacro-redefined] > #define PAGE_SIZE (1<^ > /wrkdirs/usr/ports/emulators/virtualbox-ose-additions-nox11/work/VirtualBox-5.2.14/include/iprt/param.h:52:10: > note: previous definition is here > # define PAGE_SIZE 4096 > ^ > > > Context: > > > # uname -apKU > FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r336301M amd64 amd64 > 1200072 1200072 > > > > # svnlite info /usr/ports | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 474654 > Last Changed Rev: 474654 > > > > The "M" in r336301M is mostly for use with powerpc* family experiments based > on modern C/C++ compilers: > > # svnlite status /usr/src/ | sort > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/GENERIC-DBG > ? /usr/src/sys/arm/conf/GENERIC-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/Makefile.libcompat > M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp > M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp > M /usr/src/crypto/openssl/crypto/armcap.c > M /usr/src/lib/libkvm/kvm_powerpc.c > M /usr/src/lib/libkvm/kvm_private.c > M /usr/src/release/Makefile.vm > M /usr/src/release/scripts/mk-vmimage.sh > M /usr/src/release/tools/vmimage.subr > M /usr/src/secure/lib/libcrypto/Makefile > M /usr/src/stand/defs.mk > M /usr/src/stand/powerpc/boot1.chrp/Makefile > M /usr/src/stand/powerpc/kboot/Makefile > M /usr/src/sys/arm64/arm64/identcpu.c > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/conf/ldscript.powerpc > M /usr/src/sys/powerpc/aim/mmu_oea64.c > M /usr/src/sys/powerpc/ofw/ofw_machdep.c emulators/virtualbox-ose-additions also got the error. But it did not get the PAGE_SIZE warning. There was also in both variants the likes of (3 times for each): /wrkdirs/usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-5.2.14/src/VBox/Runtime/common/asm/ASMSerializeInstruction-iret.asm:46: warning: `ss' segment register ignored in 64-bit mode And there were lots of notices for: warning: flexible array members are a C99 feature [-Wc99-extensions] warning: 'register' storage class specifier is
Re: [PATCH] Recent libm additions
On Sun, 2018-07-15 at 08:06 -0700, Steve Kargl wrote:
> Apparently, the recents additions to libm were not
> subject to any code review. The following patch
> does two things. First, it works around
>
> https://bugs.llvm.org/show_bug.cgi?id=8532
>
> Second, it removes the pollution of libm with the
> polevll.c functions. Those functions are used
> only in ld80/e_powl.c, and those functions should
> be inlined.
>
> Index: Makefile
> ===
> --- Makefile (revision 336304)
> +++ Makefile (working copy)
> @@ -56,7 +56,6 @@
> imprecise.c \
> k_cos.c k_cosf.c k_exp.c k_expf.c k_rem_pio2.c k_sin.c k_sinf.c \
> k_tan.c k_tanf.c \
> - polevll.c \
> s_asinh.c s_asinhf.c s_atan.c s_atanf.c s_carg.c s_cargf.c s_cargl.c \
> s_cbrt.c s_cbrtf.c s_ceil.c s_ceilf.c s_clog.c s_clogf.c \
> s_copysign.c s_copysignf.c s_cos.c s_cosf.c \
> Index: ld80/e_powl.c
> ===
> --- ld80/e_powl.c (revision 336304)
> +++ ld80/e_powl.c (working copy)
> @@ -77,6 +77,7 @@
> #include
>
> #include "math_private.h"
> +#include "polevll.c"
>
> /* Table size */
> #define NXT 32
> Index: src/math_private.h
> ===
> --- src/math_private.h(revision 336304)
> +++ src/math_private.h(working copy)
> @@ -828,7 +828,4 @@
> long double __kernel_cosl(long double, long double);
> long double __kernel_tanl(long double, long double, int);
>
> -long double __p1evll(long double, void *, int);
> -long double __polevll(long double, void *, int);
> -
> #endif /* !_MATH_PRIVATE_H_ */
> Index: src/polevll.c
> ===
> --- src/polevll.c (revision 336304)
> +++ src/polevll.c (working copy)
> @@ -69,7 +69,7 @@
> * Polynomial evaluator:
> * P[0] x^n + P[1] x^(n-1) + ... + P[n]
> */
> -long double
> +static inline long double
> __polevll(long double x, void *PP, int n)
> {
> long double y;
> @@ -88,7 +88,7 @@
> * Polynomial evaluator:
> * x^n + P[0] x^(n-1) + P[1] x^(n-2) + ... + P[n]
> */
> -long double
> +static inline long double
> __p1evll(long double x, void *PP, int n)
> {
> long double y;
> Index: src/s_cpow.c
> ===
> --- src/s_cpow.c (revision 336304)
> +++ src/s_cpow.c (working copy)
> @@ -60,7 +60,7 @@
> y = cimag (z);
> absa = cabs (a);
> if (absa == 0.0) {
> - return (0.0 + 0.0 * I);
> + return (CMPLX(0.0, 0.0));
> }
> arga = carg (a);
> r = pow (absa, x);
> @@ -69,6 +69,6 @@
> r = r * exp (-y * arga);
> theta = theta + y * log (absa);
> }
> - w = r * cos (theta) + (r * sin (theta)) * I;
> + w = CMPLX(r * cos (theta), r * sin (theta));
> return (w);
> }
> Index: src/s_cpowf.c
> ===
> --- src/s_cpowf.c (revision 336304)
> +++ src/s_cpowf.c (working copy)
> @@ -59,7 +59,7 @@
> y = cimagf(z);
> absa = cabsf (a);
> if (absa == 0.0f) {
> - return (0.0f + 0.0f * I);
> + return (CMPLXF(0.0f, 0.0f));
> }
> arga = cargf (a);
> r = powf (absa, x);
> @@ -68,6 +68,6 @@
> r = r * expf (-y * arga);
> theta = theta + y * logf (absa);
> }
> - w = r * cosf (theta) + (r * sinf (theta)) * I;
> + w = CMPLXF(r * cosf (theta), r * sinf (theta));
> return (w);
> }
> Index: src/s_cpowl.c
> ===
> --- src/s_cpowl.c (revision 336304)
> +++ src/s_cpowl.c (working copy)
> @@ -59,7 +59,7 @@
> y = cimagl(z);
> absa = cabsl(a);
> if (absa == 0.0L) {
> - return (0.0L + 0.0L * I);
> + return (CMPLXL(0.0L, 0.0L));
> }
> arga = cargl(a);
> r = powl(absa, x);
> @@ -68,6 +68,6 @@
> r = r * expl(-y * arga);
> theta = theta + y * logl(absa);
> }
> - w = r * cosl(theta) + (r * sinl(theta)) * I;
> + w = CMPLXL(r * cosl(theta), r * sinl(theta));
> return (w);
> }
>
If a file contains inline function definitions and is intended only to
be included into another file and not compiled separately, shouldn't
its name be spelled polevll.h ?
-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 11:00:41AM -0600, Ian Lepore wrote: > On Sun, 2018-07-15 at 08:06 -0700, Steve Kargl wrote: > > Index: ld80/e_powl.c > > === > > --- ld80/e_powl.c (revision 336304) > > +++ ld80/e_powl.c (working copy) > > @@ -77,6 +77,7 @@ > > #include > > > > #include "math_private.h" > > +#include "polevll.c" > > If a file contains inline function definitions and is intended only to > be included into another file and not compiled separately, shouldn't > its name be spelled polevll.h ? > Well, actually, the functions in polevll.c should have been copied into ld80/e_powl.c, and polevall.c should never have been committed. Unfortunately, the code was not reviewed for correctness. I've made the minimum changes to address the two issues I've noted. Feel free to either copy the functions and delete the polevall.c or rename it. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
> > Well, actually, the functions in polevll.c should have been copied > into ld80/e_powl.c, and polevall.c should never have been committed. > Unfortunately, the code was not reviewed for correctness. That is not correct. Please stop repeating it. Bruce Evans and John Baldwin were both looped in. Neither made this observation. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018, 11:23 AM K. Macy wrote: > > > > Well, actually, the functions in polevll.c should have been copied > > into ld80/e_powl.c, and polevall.c should never have been committed. > > Unfortunately, the code was not reviewed for correctness. > > That is not correct. Please stop repeating it. Bruce Evans and John > Baldwin were both looped in. Neither made this observation. > Steve is the fp guy these days. And it wasn't reviewed by him. He's mad you cut him out of the loop. Arguing about pedantic points of process does no one any good. Warner ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 10:55 AM, Warner Losh wrote: > On Sun, Jul 15, 2018, 11:23 AM K. Macy wrote: > >> > >> > Well, actually, the functions in polevll.c should have been copied >> > into ld80/e_powl.c, and polevall.c should never have been committed. >> > Unfortunately, the code was not reviewed for correctness. >> >> That is not correct. Please stop repeating it. Bruce Evans and John >> Baldwin were both looped in. Neither made this observation. >> > > Steve is the fp guy these days. And it wasn't reviewed by him. He's mad you > cut him out of the loop. Arguing about pedantic points of process does no > one any good. Thanks for the tip. I'm sorry. I was under the impression that he gave up his bit: https://reviews.freebsd.org/rD46886 So we have a maintainer who has opted to not have a bit. So be it. Nonetheless, reviews.freebsd.org is the established channel by which the project does code reviews. I stand by my recommendation and will add him to reviews in the future. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, 2018-07-15 at 11:55 -0600, Warner Losh wrote: > On Sun, Jul 15, 2018, 11:23 AM K. Macy wrote: > > > > > > > > > > > > Well, actually, the functions in polevll.c should have been > > > copied > > > into ld80/e_powl.c, and polevall.c should never have been > > > committed. > > > Unfortunately, the code was not reviewed for correctness. > > That is not correct. Please stop repeating it. Bruce Evans and John > > Baldwin were both looped in. Neither made this observation. > > > Steve is the fp guy these days. And it wasn't reviewed by him. He's > mad you > cut him out of the loop. Arguing about pedantic points of process > does no > one any good. > > Warner On the other hand, what information is there for someone to know that Steve should be involved in a review? There is nothing in MAINTAINERS. The review was on phab for almost a month, and phab is supposedly the preferred way to do reviews these days. Steve is no longer a committer, but that doesn't preclude him having a phab account and participating in reviews. If he doesn't like using phab (and I can certainly understand that POV), an entry in MAINTAINERS would still be helpful, unless we have a rule that only committers can be listed in there. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 10:21:25AM -0700, K. Macy wrote: > > > > Well, actually, the functions in polevll.c should have been copied > > into ld80/e_powl.c, and polevall.c should never have been committed. > > Unfortunately, the code was not reviewed for correctness. > > That is not correct. Please stop repeating it. Bruce Evans and John > Baldwin were both looped in. Neither made this observation. I read the differential review. The code was not reviewed by John. He reviewed how it was hooked into the build. Bruce does not appear in the differential review. There is no record on freebsd-numerics about the patch. powl on i686-class hardware is likely broken as it does not use the LD80C macro to construct literal constants. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 12:06:47PM -0600, Ian Lepore wrote: > > On the other hand, what information is there for someone to know that > Steve should be involved in a review? There is nothing in MAINTAINERS. > The review was on phab for almost a month, and phab is supposedly the > preferred way to do reviews these days. > > Steve is no longer a committer, but that doesn't preclude him having a > phab account and participating in reviews. If he doesn't like using > phab (and I can certainly understand that POV), an entry in MAINTAINERS > would still be helpful, unless we have a rule that only committers can > be listed in there. > Patch should be sent the the freebsd-numeric mailing list. phab appear after I was forced to hand in my commit bit, so I don't have a phab account. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 10:44:28AM -0700, Matthew Macy wrote: > > In the bug report you cite, Chris Lattner states: "This is actually an > unspecified feature of C99 (whether it supports the _Imaginary type). > It is desirable to support this, but not a regression. > Chris Lattner is wrong when the use of I in an express gives the wrong answer. He can claim Annex F and G are non-normative, but a wrong answer is still wrong. Go read msun/src/math_private.h. FreeBSD clearly does not use I in libm code, because it has consequences for floating point numerical code. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 10:17 AM, Steve Kargl wrote: > On Sun, Jul 15, 2018 at 11:00:41AM -0600, Ian Lepore wrote: >> On Sun, 2018-07-15 at 08:06 -0700, Steve Kargl wrote: >> > Index: ld80/e_powl.c >> > === >> > --- ld80/e_powl.c (revision 336304) >> > +++ ld80/e_powl.c (working copy) >> > @@ -77,6 +77,7 @@ >> > #include >> > >> > #include "math_private.h" >> > +#include "polevll.c" >> >> If a file contains inline function definitions and is intended only to >> be included into another file and not compiled separately, shouldn't >> its name be spelled polevll.h ? >> > > Well, actually, the functions in polevll.c should have been copied > into ld80/e_powl.c, and polevall.c should never have been committed. > Unfortunately, the code was not reviewed for correctness. I've > made the minimum changes to address the two issues I've noted. > Feel free to either copy the functions and delete the polevall.c > or rename it. > In the bug report you cite, Chris Lattner states: "This is actually an unspecified feature of C99 (whether it supports the _Imaginary type). It is desirable to support this, but not a regression. I'm more than happy to commit these changes, but neither including a .c file nor compensating for the absence of a gcc feature in clang is a correctness fix. In the future you might wish to subscribe to phab reviews so that you can be notified when changes like this are under consideration. Thank you for your input. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 11:33 AM, Steve Kargl wrote: > On Sun, Jul 15, 2018 at 12:06:47PM -0600, Ian Lepore wrote: >> >> On the other hand, what information is there for someone to know that >> Steve should be involved in a review? There is nothing in MAINTAINERS. >> The review was on phab for almost a month, and phab is supposedly the >> preferred way to do reviews these days. >> >> Steve is no longer a committer, but that doesn't preclude him having a >> phab account and participating in reviews. If he doesn't like using >> phab (and I can certainly understand that POV), an entry in MAINTAINERS >> would still be helpful, unless we have a rule that only committers can >> be listed in there. >> > > Patch should be sent the the freebsd-numeric mailing list. > phab appear after I was forced to hand in my commit bit, so > I don't have a phab account. Anyone can have a phab account. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: [PATCH] Recent libm additions
I don't think it makes sense for a non-committer to have a lock on anything in base. However a request for review makes a lot of sense. If a non-committer or former committer is the SME on a particular subject it's best that they be consulted even if they don't request it. IMO more input is better. Where better to document this than in MAINTAINERS. Having said all this. If a person is a former committer and it's not documented, how are we to know? If people agree, should we start documenting SMEs in MAINTAINERS? --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Ian Lepore Sent: 15/07/2018 11:08 To: Warner Losh; K. Macy Cc: Steve Kargl; FreeBSD Current Subject: Re: [PATCH] Recent libm additions On Sun, 2018-07-15 at 11:55 -0600, Warner Losh wrote: > On Sun, Jul 15, 2018, 11:23 AM K. Macy wrote: > > > > > > > > > > > > Well, actually, the functions in polevll.c should have been > > > copied > > > into ld80/e_powl.c, and polevall.c should never have been > > > committed. > > > Unfortunately, the code was not reviewed for correctness. > > That is not correct. Please stop repeating it. Bruce Evans and John > > Baldwin were both looped in. Neither made this observation. > > > Steve is the fp guy these days. And it wasn't reviewed by him. He's > mad you > cut him out of the loop. Arguing about pedantic points of process > does no > one any good. > > Warner On the other hand, what information is there for someone to know that Steve should be involved in a review? There is nothing in MAINTAINERS. The review was on phab for almost a month, and phab is supposedly the preferred way to do reviews these days. Steve is no longer a committer, but that doesn't preclude him having a phab account and participating in reviews. If he doesn't like using phab (and I can certainly understand that POV), an entry in MAINTAINERS would still be helpful, unless we have a rule that only committers can be listed in there. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
I'm not saying that he has a lock. I'm saying he's are domain expert and many mistakes can be avoided by talking to him. I'm saying we have history here, and that history, while poorly documented, wasn't followed. To the extent it is poorly documented, we should fix that. Warner On Sun, Jul 15, 2018 at 12:43 PM, Cy Schubert wrote: > I don't think it makes sense for a non-committer to have a lock on > anything in base. However a request for review makes a lot of sense. If a > non-committer or former committer is the SME on a particular subject it's > best that they be consulted even if they don't request it. IMO more input > is better. Where better to document this than in MAINTAINERS. > > Having said all this. If a person is a former committer and it's not > documented, how are we to know? > > If people agree, should we start documenting SMEs in MAINTAINERS? > > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > -- > From: Ian Lepore > Sent: 15/07/2018 11:08 > To: Warner Losh; K. Macy > Cc: Steve Kargl; FreeBSD Current > Subject: Re: [PATCH] Recent libm additions > > On Sun, 2018-07-15 at 11:55 -0600, Warner Losh wrote: > > On Sun, Jul 15, 2018, 11:23 AM K. Macy wrote: > > > > > > > > > > > > > > > > > Well, actually, the functions in polevll.c should have been > > > > copied > > > > into ld80/e_powl.c, and polevall.c should never have been > > > > committed. > > > > Unfortunately, the code was not reviewed for correctness. > > > That is not correct. Please stop repeating it. Bruce Evans and John > > > Baldwin were both looped in. Neither made this observation. > > > > > Steve is the fp guy these days. And it wasn't reviewed by him. He's > > mad you > > cut him out of the loop. Arguing about pedantic points of process > > does no > > one any good. > > > > Warner > > On the other hand, what information is there for someone to know that > Steve should be involved in a review? There is nothing in MAINTAINERS. > The review was on phab for almost a month, and phab is supposedly the > preferred way to do reviews these days. > > Steve is no longer a committer, but that doesn't preclude him having a > phab account and participating in reviews. If he doesn't like using > phab (and I can certainly understand that POV), an entry in MAINTAINERS > would still be helpful, unless we have a rule that only committers can > be listed in there. > > -- Ian > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: [PATCH] Recent libm additions
I wasn't saying Steve has a lock however in case non-committers might feel they do, addressing all points in my reply. Not saying anyone feels this way today but we should consider this in whatever we decide here (considering all possibilities). IMO adding subject matter experts to MAINTAINERS seems like the easiest way to document who might be the go-to person. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Warner Losh Sent: 15/07/2018 12:09 To: Cy Schubert Cc: Ian Lepore; K. Macy; Steve Kargl; FreeBSD Current Subject: Re: [PATCH] Recent libm additions I'm not saying that he has a lock. I'm saying he's are domain expert and many mistakes can be avoided by talking to him. I'm saying we have history here, and that history, while poorly documented, wasn't followed. To the extent it is poorly documented, we should fix that. Warner On Sun, Jul 15, 2018 at 12:43 PM, Cy Schubert wrote: I don't think it makes sense for a non-committer to have a lock on anything in base. However a request for review makes a lot of sense. If a non-committer or former committer is the SME on a particular subject it's best that they be consulted even if they don't request it. IMO more input is better. Where better to document this than in MAINTAINERS. Having said all this. If a person is a former committer and it's not documented, how are we to know? If people agree, should we start documenting SMEs in MAINTAINERS? --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- From: Ian Lepore Sent: 15/07/2018 11:08 To: Warner Losh; K. Macy Cc: Steve Kargl; FreeBSD Current Subject: Re: [PATCH] Recent libm additions On Sun, 2018-07-15 at 11:55 -0600, Warner Losh wrote: > On Sun, Jul 15, 2018, 11:23 AM K. Macy wrote: > > > > > > > > > > > > Well, actually, the functions in polevll.c should have been > > > copied > > > into ld80/e_powl.c, and polevall.c should never have been > > > committed. > > > Unfortunately, the code was not reviewed for correctness. > > That is not correct. Please stop repeating it. Bruce Evans and John > > Baldwin were both looped in. Neither made this observation. > > > Steve is the fp guy these days. And it wasn't reviewed by him. He's > mad you > cut him out of the loop. Arguing about pedantic points of process > does no > one any good. > > Warner On the other hand, what information is there for someone to know that Steve should be involved in a review? There is nothing in MAINTAINERS. The review was on phab for almost a month, and phab is supposedly the preferred way to do reviews these days. Steve is no longer a committer, but that doesn't preclude him having a phab account and participating in reviews. If he doesn't like using phab (and I can certainly understand that POV), an entry in MAINTAINERS would still be helpful, unless we have a rule that only committers can be listed in there. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
So something like this: diff --git a/MAINTAINERS b/MAINTAINERS index 51d3688f8b8..3e6584f24a1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -58,6 +58,7 @@ kqueuejmg Pre-commit review requested. Documentation Required. libdpv dteske Pre-commit review requested. Keep in sync with dpv(1). libfetch des Pre-commit review requested, email only. libfigpar dteske Pre-commit review requested. +libm freebsd-numericsSend email with patches to freebsd-numerics@ libpam des Pre-commit review requested, email only. linprocfs des Pre-commit review requested, email only. lprgad Pre-commit review requested, particularly for is what you're suggesting? Warner On Sun, Jul 15, 2018 at 1:23 PM, Cy Schubert wrote: > I wasn't saying Steve has a lock however in case non-committers might feel > they do, addressing all points in my reply. Not saying anyone feels this > way today but we should consider this in whatever we decide here > (considering all possibilities). IMO adding subject matter experts to > MAINTAINERS seems like the easiest way to document who might be the go-to > person. > > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > -- > From: Warner Losh > Sent: 15/07/2018 12:09 > To: Cy Schubert > Cc: Ian Lepore; K. Macy; Steve Kargl; FreeBSD Current > > Subject: Re: [PATCH] Recent libm additions > > I'm not saying that he has a lock. I'm saying he's are domain expert and > many mistakes can be avoided by talking to him. > > I'm saying we have history here, and that history, while poorly > documented, wasn't followed. To the extent it is poorly documented, we > should fix that. > > Warner > > On Sun, Jul 15, 2018 at 12:43 PM, Cy Schubert > wrote: > >> I don't think it makes sense for a non-committer to have a lock on >> anything in base. However a request for review makes a lot of sense. If a >> non-committer or former committer is the SME on a particular subject it's >> best that they be consulted even if they don't request it. IMO more input >> is better. Where better to document this than in MAINTAINERS. >> >> Having said all this. If a person is a former committer and it's not >> documented, how are we to know? >> >> If people agree, should we start documenting SMEs in MAINTAINERS? >> >> --- >> Sent using a tiny phone keyboard. >> Apologies for any typos and autocorrect. >> Also, this old phone only supports top post. Apologies. >> >> Cy Schubert >> or >> The need of the many outweighs the greed of the few. >> --- >> -- >> From: Ian Lepore >> Sent: 15/07/2018 11:08 >> To: Warner Losh; K. Macy >> Cc: Steve Kargl; FreeBSD Current >> Subject: Re: [PATCH] Recent libm additions >> >> On Sun, 2018-07-15 at 11:55 -0600, Warner Losh wrote: >> > On Sun, Jul 15, 2018, 11:23 AM K. Macy wrote: >> > >> > > >> > > > >> > > > >> > > > Well, actually, the functions in polevll.c should have been >> > > > copied >> > > > into ld80/e_powl.c, and polevall.c should never have been >> > > > committed. >> > > > Unfortunately, the code was not reviewed for correctness. >> > > That is not correct. Please stop repeating it. Bruce Evans and John >> > > Baldwin were both looped in. Neither made this observation. >> > > >> > Steve is the fp guy these days. And it wasn't reviewed by him. He's >> > mad you >> > cut him out of the loop. Arguing about pedantic points of process >> > does no >> > one any good. >> > >> > Warner >> >> On the other hand, what information is there for someone to know that >> Steve should be involved in a review? There is nothing in MAINTAINERS. >> The review was on phab for almost a month, and phab is supposedly the >> preferred way to do reviews these days. >> >> Steve is no longer a committer, but that doesn't preclude him having a >> phab account and participating in reviews. If he doesn't like using >> phab (and I can certainly understand that POV), an entry in MAINTAINERS >> would still be helpful, unless we have a rule that only committers can >> be listed in there. >> >> -- Ian >> >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org >> " >> >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On 07/15/2018 02:09 PM, Warner Losh wrote: > I'm not saying that he has a lock. I'm saying he's are domain expert and > many mistakes can be avoided by talking to him. > > I'm saying we have history here, and that history, while poorly documented, > wasn't followed. To the extent it is poorly documented, we should fix that. > > Warner > I agree that we should document the process. Maybe also include freebsd-numerics@ on these discussions, as that is why it was created. But I'm really glad these changes were committed. I have found the people tend to drag their feet a lot on numerics issues. Has anyone done an analysis of the OpenBSD powl functions from an accuracy point of view? That is, to test how many ULP of error these functions have? If not, I could give it a go, although not for several months because life is very busy. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: [PATCH] Recent libm additions
That'll work too. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Warner Losh Sent: 15/07/2018 12:26 To: Cy Schubert Cc: Ian Lepore; K. Macy; Steve Kargl; FreeBSD Current Subject: Re: [PATCH] Recent libm additions So something like this: diff --git a/MAINTAINERS b/MAINTAINERS index 51d3688f8b8..3e6584f24a1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -58,6 +58,7 @@ kqueuejmg Pre-commit review requested. Documentation Required. libdpv dteske Pre-commit review requested. Keep in sync with dpv(1). libfetch des Pre-commit review requested, email only. libfigpar dteske Pre-commit review requested. +libm freebsd-numericsSend email with patches to freebsd-numerics@ libpam des Pre-commit review requested, email only. linprocfs des Pre-commit review requested, email only. lprgad Pre-commit review requested, particularly for is what you're suggesting? Warner On Sun, Jul 15, 2018 at 1:23 PM, Cy Schubert wrote: I wasn't saying Steve has a lock however in case non-committers might feel they do, addressing all points in my reply. Not saying anyone feels this way today but we should consider this in whatever we decide here (considering all possibilities). IMO adding subject matter experts to MAINTAINERS seems like the easiest way to document who might be the go-to person. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- From: Warner Losh Sent: 15/07/2018 12:09 To: Cy Schubert Cc: Ian Lepore; K. Macy; Steve Kargl; FreeBSD Current Subject: Re: [PATCH] Recent libm additions I'm not saying that he has a lock. I'm saying he's are domain expert and many mistakes can be avoided by talking to him. I'm saying we have history here, and that history, while poorly documented, wasn't followed. To the extent it is poorly documented, we should fix that. Warner On Sun, Jul 15, 2018 at 12:43 PM, Cy Schubert wrote: I don't think it makes sense for a non-committer to have a lock on anything in base. However a request for review makes a lot of sense. If a non-committer or former committer is the SME on a particular subject it's best that they be consulted even if they don't request it. IMO more input is better. Where better to document this than in MAINTAINERS. Having said all this. If a person is a former committer and it's not documented, how are we to know? If people agree, should we start documenting SMEs in MAINTAINERS? --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- From: Ian Lepore Sent: 15/07/2018 11:08 To: Warner Losh; K. Macy Cc: Steve Kargl; FreeBSD Current Subject: Re: [PATCH] Recent libm additions On Sun, 2018-07-15 at 11:55 -0600, Warner Losh wrote: > On Sun, Jul 15, 2018, 11:23 AM K. Macy wrote: > > > > > > > > > > > > Well, actually, the functions in polevll.c should have been > > > copied > > > into ld80/e_powl.c, and polevall.c should never have been > > > committed. > > > Unfortunately, the code was not reviewed for correctness. > > That is not correct. Please stop repeating it. Bruce Evans and John > > Baldwin were both looped in. Neither made this observation. > > > Steve is the fp guy these days. And it wasn't reviewed by him. He's > mad you > cut him out of the loop. Arguing about pedantic points of process > does no > one any good. > > Warner On the other hand, what information is there for someone to know that Steve should be involved in a review? There is nothing in MAINTAINERS. The review was on phab for almost a month, and phab is supposedly the preferred way to do reviews these days. Steve is no longer a committer, but that doesn't preclude him having a phab account and participating in reviews. If he doesn't like using phab (and I can certainly understand that POV), an entry in MAINTAINERS would still be helpful, unless we have a rule that only committers can be listed in there. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFSv4.1 server deficiencies fixed for ESXi client
Rodney W. Grimes wrote: >Have you any contact with VMWare so that they might fix the issues >in thier code, rather than having to put hacks in FreeBSD for these >issues? Well, Jim White (who is not in their file system area) submitted a PR on their system and the response was along the lines of: Sorry to report the storage team punted the bug to a future release (which could be indefinite). The stated reason is that FreeBSD isn't a supported NFS 4.1 server. As such, it didn't sound too promising. However, recent tests have shown that ESXi6.7 is much better. The packet traces I've seen sofar for the ESXi 6.7 client show none of the serious (and difficult to deal with without violating the RFC) problems. It still does a ReclaimComplete with rca_one_fs == TRUE, but it also does the required ReclaimComplete with rca_one_fs == FALSE. Although I believe the ReclaimComplete with rca_one_fs == TRUE is only meant to be used after a file system has been transferred to a different server (something the FreeBSD server does not do at this time), the RFC is somewhat vague on when this is used, so I think just replying NFS_OK to this without doing anything should be acceptable. (I am going to look and see what the Linux server does for this case.) As such, I'm hoping that there will be no need for "dirty hacks" for the ESXi6.7 client and this might soon be resolved. Thanks go to those doing the testing (Andreas Nagy and Daniel Engel) and Jim White for submitting the PR that somehow got fixed in a matter of days, rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 12:23:06PM -0700, Cy Schubert wrote: > I wasn't saying Steve has a lock however in case non-committers > might feel they do, addressing all points in my reply. Not saying > anyone feels this way today but we should consider this in whatever > we decide here (considering all possibilities). IMO adding subject > matter experts to MAINTAINERS seems like the easiest way to document > who might be the go-to person. I don't have a lock, and I don't want one. I do, however, make a part of my living using FreeBSD for floating point intensive research. I think that changes, including the addition of new functions, to libm should be reviewed and preferably tested. Grabbing code from OpenBSD (or anywhere), getting it to compile and integrated into the build infrastructure does not constitute a code review. There is a mailing list dedicated to numerics (aka floating point) on FreeBSD: freebsd-numer...@freebsd.org. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 02:00:37PM -0700, Matthew Macy wrote: > On Sun, Jul 15, 2018 at 12:43 PM, Montgomery-Smith, Stephen > wrote: > > On 07/15/2018 02:09 PM, Warner Losh wrote: > >> I'm not saying that he has a lock. I'm saying he's are domain expert and > >> many mistakes can be avoided by talking to him. > >> > >> I'm saying we have history here, and that history, while poorly documented, > >> wasn't followed. To the extent it is poorly documented, we should fix that. > >> > >> Warner > >> > > I agree that we should document the process. Maybe also include > > freebsd-numerics@ on these discussions, as that is why it was created. > > > > But I'm really glad these changes were committed. I have found the > > people tend to drag their feet a lot on numerics issues. > > > > Has anyone done an analysis of the OpenBSD powl functions from an > > accuracy point of view? That is, to test how many ULP of error these > > functions have? If not, I could give it a go, although not for several > > months because life is very busy. > > They're also used by Julia. You might ask there first. The FPU on i686-class hardware is set to use 53-bit precision. powl.c likely has at least a 2**11 ULP for a (large?) number of arguments. Go read the msun/src/math_private.h. You'll find LD80C for constucting long double literal constants, ENTERI() and RETURNI() marcos that toggle the precision of the FPU. These are used in ld80 code, e.g., e_lgammal_r.c. So, it doesn't matter what the Julia developers say unless their testing was done on FreeBSD. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 02:00:37PM -0700, Matthew Macy wrote: > On Sun, Jul 15, 2018 at 12:43 PM, Montgomery-Smith, Stephen > wrote: > > On 07/15/2018 02:09 PM, Warner Losh wrote: > >> I'm not saying that he has a lock. I'm saying he's are domain expert and > >> many mistakes can be avoided by talking to him. > >> > >> I'm saying we have history here, and that history, while poorly documented, > >> wasn't followed. To the extent it is poorly documented, we should fix that. > >> > >> Warner > >> > > I agree that we should document the process. Maybe also include > > freebsd-numerics@ on these discussions, as that is why it was created. > > > > But I'm really glad these changes were committed. I have found the > > people tend to drag their feet a lot on numerics issues. > > > > Has anyone done an analysis of the OpenBSD powl functions from an > > accuracy point of view? That is, to test how many ULP of error these > > functions have? If not, I could give it a go, although not for several > > months because life is very busy. > > They're also used by Julia. You might ask there first. You also need to fix the pow.3 documentation. It currently states BUGS To conform with newer C/C++ standards, a stub implementation for powl was committed to the math library, where powl is mapped to pow. Thus, the numerical accuracy is at most that of the 53-bit double precision implementation. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 12:43 PM, Montgomery-Smith, Stephen wrote: > On 07/15/2018 02:09 PM, Warner Losh wrote: >> I'm not saying that he has a lock. I'm saying he's are domain expert and >> many mistakes can be avoided by talking to him. >> >> I'm saying we have history here, and that history, while poorly documented, >> wasn't followed. To the extent it is poorly documented, we should fix that. >> >> Warner >> > I agree that we should document the process. Maybe also include > freebsd-numerics@ on these discussions, as that is why it was created. > > But I'm really glad these changes were committed. I have found the > people tend to drag their feet a lot on numerics issues. > > Has anyone done an analysis of the OpenBSD powl functions from an > accuracy point of view? That is, to test how many ULP of error these > functions have? If not, I could give it a go, although not for several > months because life is very busy. They're also used by Julia. You might ask there first. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Recent libm additions
On Sun, Jul 15, 2018 at 01:09:41PM -0600, Warner Losh wrote: > I'm not saying that he has a lock. I'm saying he's are domain expert > and many mistakes can be avoided by talking to him. fwiw, substantially all the work done since at least 2013 is from kargl. (I am eliding the licensing, Makefile, and typo commits.) https://svnweb.freebsd.org/base/head/lib/msun/src/?sortby=date#dirlist mcl ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: em0 link fail
On 07/05/18 09:54, I wrote: > On 07/05/18 09:27, tech-lists wrote: >> On 03/07/2018 19:47, Michael Butler wrote: >>> That would've been .. >>> >>> Jun 1 09:56:15 toshi kernel: FreeBSD 12.0-CURRENT #35 r334484: Fri Jun >>> 1 08:25:58 EDT 2018 >>> >>> I'm going to build one with SVN r334862 reverted to see if that works, >> >> Hi, >> >> Is it working now? Am asking because a system I'd like to take from >> 11-stable to 12 uses the em driver. > > No :-( I haven't had the chance yet to revisit it, As it turns out, SVN r336313 (committed today) solves the issue I was having with the hardware stalling, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFSv4.1 server deficiencies fixed for ESXi client
I wrote: > (I am going to look and see what the Linux server does for this case.) I just looked and the Linux 4.17-rc2 kernel NFS server just returns NFS_OK for the rca_one_fs == TRUE case. I have given a patch that does the same thing for the FreeBSD server to Andreas and Daniel and think it is ok to commit, if it works. (I don't think it violates the RFC, since the RFC is vague w.r.t. when the rca_one_fs == TRUE case is used and never mentions that an error should be returned when the server doesn't use it. rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
