Re: Optimization bug with floating-point?

2019-03-13 Thread Steve Kargl
On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > > cc -O -fno-builtin -o z a.c -lm && ./z > cc -O2 -fno-builtin -o z a.c -lm && ./z > cc -O3 -fno-builtin -o z a.c -lm && ./z > > > Max ULP: 23.061242 > Count: 39 (# of ULP that exceeds 21) > These results do not change if

Re: Optimization bug with floating-point?

2019-03-13 Thread Steve Kargl
On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > > gcc8 --version > gcc8 (FreeBSD Ports Collection) 8.3.0 > > gcc8 -fno-builtin -o z a.c -lm && ./z > gcc8 -O -fno-builtin -o z a.c -lm && ./z > gcc8 -O2 -fno-builtin -o z a.c -lm && ./z > gcc8 -O3 -fno-builtin -o z a.c -lm && ./z >

A question about statclock and stathz

2019-03-13 Thread Thomas Sparrevohn
A little while ago I decided to write a little program with the aim of analysing the historical memory usage of my FreeBSD system based on the system account files in the /var/account. While the reasons for this are obscure and irrelevant. I was somewhat surprised to discover that about 43% of

Re: kqueue send over unix socket?

2019-03-13 Thread Jan Bramkamp
On 12.03.19 22:52, Aki Tuomi wrote: > Hi! > > I am trying exactly that. As others have already stated kqueue file descriptors can leave the process that created them (neither through file descriptor passing nor through inheritance). Can you tell us why you want to send the kqueue file descriptor

Re: Optimization bug with floating-point?

2019-03-13 Thread Steve Kargl
On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > All, > > There seems to an optimization bug with clang on > > % uname -a > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386 > > IOW, if you do numerica work on i386, you may want to check your > results. > >

Re: Optimization bug with floating-point?

2019-03-13 Thread Steve Kargl
On Wed, Mar 13, 2019 at 04:56:26PM +0100, Hans Petter Selasky wrote: > On 3/13/19 4:50 PM, Steve Kargl wrote: > > Using sin() and cos() directly as in > > > > /* Double precision csinh() without using C's double complex.s */ > > void > > dp_csinh(double x, double y, double *re, double *im) > > {

Re: Optimization bug with floating-point?

2019-03-13 Thread John Baldwin
On 3/13/19 8:16 AM, Steve Kargl wrote: > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: >> >> gcc8 --version >> gcc8 (FreeBSD Ports Collection) 8.3.0 >> >> gcc8 -fno-builtin -o z a.c -lm && ./z >> gcc8 -O -fno-builtin -o z a.c -lm && ./z >> gcc8 -O2 -fno-builtin -o z a.c -lm && ./z

Re: Optimization bug with floating-point?

2019-03-13 Thread Steve Kargl
On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: > On 3/13/19 8:16 AM, Steve Kargl wrote: > > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > >> > >> gcc8 --version > >> gcc8 (FreeBSD Ports Collection) 8.3.0 > >> > >> gcc8 -fno-builtin -o z a.c -lm && ./z > >> gcc8 -O

Re: Optimization bug with floating-point?

2019-03-13 Thread Hans Petter Selasky
On 3/13/19 4:50 PM, Steve Kargl wrote: Using sin() and cos() directly as in /* Double precision csinh() without using C's double complex.s */ void dp_csinh(double x, double y, double *re, double *im) { double c, s; *re = sinh(x) * cos(y); *im = cosh(x) * sin(y); } does not change

Re: Optimization bug with floating-point?

2019-03-13 Thread Conrad Meyer
Hi John, On Wed, Mar 13, 2019 at 10:17 AM John Baldwin wrote: > One issue I'm aware of is that clang does not have any support for the > special arrangement FreeBSD/i386 uses where it uses different precision > for registers vs in-memory for some of the floating point types (GCC has > a special

Re: Optimization bug with floating-point?

2019-03-13 Thread Steve Kargl
On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote: > On 3/13/19 9:40 AM, Steve Kargl wrote: > > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: > >> On 3/13/19 8:16 AM, Steve Kargl wrote: > >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > > gcc8

Re: Optimization bug with floating-point?

2019-03-13 Thread John Baldwin
On 3/13/19 9:40 AM, Steve Kargl wrote: > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: >> On 3/13/19 8:16 AM, Steve Kargl wrote: >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: gcc8 --version gcc8 (FreeBSD Ports Collection) 8.3.0 gcc8

Re: Optimization bug with floating-point?

2019-03-13 Thread Hans Petter Selasky
On 3/13/19 4:16 PM, Steve Kargl wrote: On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: gcc8 --version gcc8 (FreeBSD Ports Collection) 8.3.0 gcc8 -fno-builtin -o z a.c -lm && ./z gcc8 -O -fno-builtin -o z a.c -lm && ./z gcc8 -O2 -fno-builtin -o z a.c -lm && ./z gcc8 -O3

Re: Optimization bug with floating-point?

2019-03-13 Thread Steve Kargl
On Wed, Mar 13, 2019 at 04:41:51PM +0100, Hans Petter Selasky wrote: > On 3/13/19 4:16 PM, Steve Kargl wrote: > > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > >> > >> gcc8 --version > >> gcc8 (FreeBSD Ports Collection) 8.3.0 > >> > >> gcc8 -fno-builtin -o z a.c -lm && ./z > >>

Re: Optimization bug with floating-point?

2019-03-13 Thread Steve Kargl
On Wed, Mar 13, 2019 at 10:40:28AM -0700, Conrad Meyer wrote: > Hi John, > > On Wed, Mar 13, 2019 at 10:17 AM John Baldwin wrote: > > One issue I'm aware of is that clang does not have any support for the > > special arrangement FreeBSD/i386 uses where it uses different precision > > for

Re: Optimization bug with floating-point?

2019-03-13 Thread Steve Kargl
On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote: > On 3/13/19 9:40 AM, Steve Kargl wrote: > > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote: > >> On 3/13/19 8:16 AM, Steve Kargl wrote: > >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote: > > gcc8

SVN r345102 breaks drm-current-kmod

2019-03-13 Thread Michael Butler
As below .. --- drm_atomic_helper.o --- In file included from /usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drivers/gpu/drm/drm_atomic_helper.c:28: In file included from /usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/include/drm/drmP.h:139: