From owner-freebsd-hackers@freebsd.org Sun May 7 01:53:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F0CFD5F506 for ; Sun, 7 May 2017 01:53:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-78.reflexion.net [208.70.210.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2C6E151 for ; Sun, 7 May 2017 01:53:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2846 invoked from network); 7 May 2017 01:53:34 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 May 2017 01:53:34 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 06 May 2017 21:53:34 -0400 (EDT) Received: (qmail 11141 invoked from network); 7 May 2017 01:53:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 May 2017 01:53:34 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E3711EC808D; Sat, 6 May 2017 18:53:33 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Panics for gcc-4.2.1-based powerpc non-debug head kernel builds (e.g., -r317820); no powerpc kernel debugger support (system or ports) Message-Id: Date: Sat, 6 May 2017 18:53:33 -0700 Cc: FreeBSD Toolchain To: FreeBSD PowerPC ML , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 01:53:43 -0000 [I'm forking off this subject from the llvm bugzilla 26519's latest partial TARET_ARCH=3Dpowerpc fix material as it seems to be independent.] I've recently been building, installing, and using TARGET_ARCH=3Dpowerpc again (because of a partial clang fix for targeting powerpc 32-bit). But the context here can be restricted to just gcc 4.2.1 based builds/installs (world and kernel), head -r317820 most recent tried. [It has been a long time since I'd last built for TARGET_ARCH=3Dpowerpc.] When I run from a debug kernel there has been no observed problems. But running from a production kernel I get occasional panics for "unknown" exceptions. I have cleared out (rm -fr) and rebuilt and reinstalled in case of corruptions, it has not made a difference. I'll note that the same machine does fine with TARGET_ARCH=3Dpowerpc64 builds (system-clang based normally for me). So far all the powerpc panics report: pid=3D11, comm=3Didle: CPU In other words: the [idle{idle: cpu}] threads. Things are unusual in various respects, such as an lr figure that is odd, like 0x907f and exception numbers that are classified as "(unknown)", for example for the number: 0x903a64e . No stack trace is produced. Nearly all the reports claim ffs_truncate+0x1080 for where but I have recently seen something else as well (not recorded, unfortunately). But I'm not sure I'd trust that aspect of the report. Unfortunately calling doadump is not all that useful. Using core.text. to illustrate: # grep unsupported /var/crash/core.txt.5 | more Failed to open vmcore: unsupported architecture ps: unsupported architecture vmstat: kvm_openfiles: unsupported architecture vmstat: kvm_openfiles: unsupported architecture vmstat: kvm_openfiles: unsupported architecture vmstat: kvm_openfiles: unsupported architecture pstat: kvm_openfiles: unsupported architecture pstat: kvm_openfiles: unsupported architecture iostat: kvm_openfiles: unsupported architecture ipcs: kvm_openfiles: unsupported architecture ipcs: kvm_openfiles: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture netstat: kvm not available: unsupported architecture fstat: kvm_openfiles(): unsupported architecture dmesg: unsupported architecture ddb: ddb_capture: kvm_openfiles: unsupported architecture Only the kernel config section is filled in for core.txt.5 (or the others). And kgdb from devel/gdb (-r440115 of /usr/ports) reports: # kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.5=20 . . . Reading symbols from /usr/lib/debug/boot/kernel/kernel.debug...done. ABI doesn't support a vmcore target By contrast with a debug kernel I was able to do buildworld buildkernel from scratch to completion and leave it sit idle for much longer than it has stayed up idle for the production kernel. (The panics are not normally frequent so this takes a while.) If I have a clang based world mixed with the gcc 4.2.1 kernels the same things apply but for powerpc at this point the better context is to stick to just gcc 4.2.1 based builds. The powerpc machine is a old PowerMac. # 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/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Target.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/sys/arm/arm/gic.h M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/kmod.mk (The Makefile* and *.mk stuff is historical from being compatible with both system and xtoolchain based activity.) I build with both sc and vt but normally use sc via /boot/loader.conf : # more /boot/loader.conf=20 kernel=3D"kernel" verbose_loading=3D"YES" kern.vty=3Dsc dumpdev=3D"/dev/label/FBSDG4Sswap" # more /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG # # GENERIC -- Custom configuration for the powerpc/powerpc # include "GENERIC" ident GENERICvtsc-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger options GDB # HACK!!! ... # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting device sc #device kbdmux # HACK: already listed by vt options SC_OFWFB # OFW frame buffer options SC_DFLT_FONT # compile font in makeoptions SC_DFLT_FONT=3Dcp437 # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones I normally run a amd64 -> powerpc cross build, in this case via gcc 4.2.1 : # more ~/src.configs/src.conf.powerpc-gcc421-bootstrap-clang.amd64-host=20= TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITHOUT_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG_FULL=3D WITHOUT_CLANG_EXTRAS=3D WITHOUT_LLD=3D WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITH_GCC_IS_CC=3D WITH_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D The amd64 context is also head -r317820 currently. Right now it looks fairly difficult to get a clue about what might be at issue for these panics. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Wed May 10 09:10:29 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58C96D65822 for ; Wed, 10 May 2017 09:10:29 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1730FA50 for ; Wed, 10 May 2017 09:10:28 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [78.47.166.52] (helo=sslproxy04.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1d8NKA-0000EB-2o for freebsd-hackers@freebsd.org; Wed, 10 May 2017 10:50:22 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy04.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d8NK9-0007hg-Q4 for freebsd-hackers@freebsd.org; Wed, 10 May 2017 10:50:21 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id A5D6E2A003F for ; Wed, 10 May 2017 10:50:47 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id am2haT7fMa0m for ; Wed, 10 May 2017 10:50:43 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 555182A160A for ; Wed, 10 May 2017 10:50:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qMURH__x9Grd for ; Wed, 10 May 2017 10:50:43 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 458AD2A003F for ; Wed, 10 May 2017 10:50:43 +0200 (CEST) To: FreeBSD From: Sebastian Huber Subject: Linux gen_pool allocator replacement? Message-ID: <5912D448.5060201@embedded-brains.de> Date: Wed, 10 May 2017 10:50:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23373/Wed May 10 07:07:49 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 09:10:29 -0000 Hello, I try currently to port a BSD licensed Linux network interface driver to=20 FreeBSD. This driver uses the gen_pool allocator http://elixir.free-electrons.com/linux/latest/source/include/linux/genall= oc.h for example here https://github.com/torvalds/linux/blob/master/drivers/soc/fsl/qbman/qman.= c#L2707 Does someone know if something similar exits in the FreeBSD kernel? I=20 cannot use UMA since the pool management data must reside outside the=20 managed memory area. One use case in this driver seems just to manage a=20 range of integers, so no actual memory allocation. For this I could=20 probably use UNR(9), but a general gen_pool allocator replacement would=20 be nice. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Wed May 10 09:20:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5C37D65C9D for ; Wed, 10 May 2017 09:20:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 646DEF6B for ; Wed, 10 May 2017 09:20:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4A9Jkwg078564 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 10 May 2017 12:19:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4A9Jkwg078564 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4A9JkW1078563; Wed, 10 May 2017 12:19:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 May 2017 12:19:46 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: FreeBSD Subject: Re: Linux gen_pool allocator replacement? Message-ID: <20170510091946.GT1622@kib.kiev.ua> References: <5912D448.5060201@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5912D448.5060201@embedded-brains.de> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 09:20:01 -0000 On Wed, May 10, 2017 at 10:50:16AM +0200, Sebastian Huber wrote: > Hello, > > I try currently to port a BSD licensed Linux network interface driver to > FreeBSD. This driver uses the gen_pool allocator > > http://elixir.free-electrons.com/linux/latest/source/include/linux/genalloc.h > > for example here > > https://github.com/torvalds/linux/blob/master/drivers/soc/fsl/qbman/qman.c#L2707 > > Does someone know if something similar exits in the FreeBSD kernel? I > cannot use UMA since the pool management data must reside outside the > managed memory area. One use case in this driver seems just to manage a I think you would get more useful answers if you explain what the facility does. > range of integers, so no actual memory allocation. For this I could > probably use UNR(9), but a general gen_pool allocator replacement would > be nice. For an abstract resource allocator, look at vmem(9). It manages arbitrary resources represented by ranges of integer values, you can use the range of size 1. There is no man page for vmem(9), but the interface is clearly explained in sys/vmem.h, and there is an article by Jeff Bonwick and Jonathan Adams about vmem, describing the original Solaris facility. From owner-freebsd-hackers@freebsd.org Wed May 10 15:55:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8928ED67304 for ; Wed, 10 May 2017 15:55:15 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from h2.pinyon.org (h2.pinyon.org [65.101.20.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66ADC1783 for ; Wed, 10 May 2017 15:55:14 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by h2.pinyon.org (Postfix, from userid 58) id 4AE882140B; Wed, 10 May 2017 08:45:54 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pinyon.org; s=DKIM; t=1494431154; bh=JAbfKqseJTXLGeB1BTr9PGD2117PsM2rujImVNQNwbk=; h=To:From:Subject:Date; b=WI79y1y6MS1gH8RP9grc46LFQi/eXlskDIMQRJ1AhChe1I3NzZ1/KTPAqiKLAclL1 aRYKMWGRPM+ISTxBOJRMslZGhnkz6WNpdy4n4WETJhZAzDjREfGzapb1WHi+ukS6RC nf+UaAdeGZOyxhu3mjCCRVkWGwRSw9tYNu5fp6Ko= X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on h2.n1.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from [10.0.10.15] (h1.pinyon.org [65.101.20.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by h2.pinyon.org (Postfix) with ESMTPSA id B355C213FB for ; Wed, 10 May 2017 08:45:53 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pinyon.org; s=DKIM; t=1494431153; bh=JAbfKqseJTXLGeB1BTr9PGD2117PsM2rujImVNQNwbk=; h=To:From:Subject:Date; b=EP6sty/WL93oAMtHiK6JrsWTse/vBv234fYmmABl/1cYunOs4GiXMQTOu115iB8Nu Ye4JZmKHR1/1ucv+2hGpFPxZYOuDdInAV9ZBSqx4Q7FXsT1NpAeEjeUrsmPK6Ma6UI kMuz0cjRFyFi8T5E3DMnIBWsSA1hXnm9qfY2jXfc= To: freebsd-hackers@freebsd.org From: "Russell L. Carter" Subject: hardware performance monitoring counters Message-ID: Date: Wed, 10 May 2017 08:45:53 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:55:15 -0000 Greetings, I'd like to use the PMC capabilities, but I seem to have a misconfiguration: root@bruno> pmccontrol -l pmccontrol: Initialization of the pmc(3) library failed: No such file or directory In my kernel conf directory: root@bruno> grep -i pmc * [...] RLCBASE:options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) [...] Both amd and intel systems have the same error on fresh 11/stable amd64 systems. Mr. google turns up people having the same problem, but no solutions. Does anyone know how I might fix this? Thanks, Russell From owner-freebsd-hackers@freebsd.org Wed May 10 16:07:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35B5AD677B3 for ; Wed, 10 May 2017 16:07:00 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E87FF360 for ; Wed, 10 May 2017 16:06:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x22a.google.com with SMTP id b68so45226ywe.3 for ; Wed, 10 May 2017 09:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UbK3ff7tkUPcHghAQTVeAf2fuJjuxHGQPDTK5XeMpGM=; b=C3ePaumKNkhm0tVXxcMXKG/3rax1T34DnGQIrC7NIzxg0xVomQc1Rb3dXc1MlJLAeW gl7f2eZ0d59ihosu6QSaCVVV2SoUeWUv22H+4AdcdsH9uE80ScsyJg88rj+r3C47N5Q4 9sCXbSO1KC5Vc309xLP4gztynnJQU+AFJUSFg/y/NOBYFtGpF3G+DUmky0Wz8QkoXO9t /bR0CXwarXuDjTM/m1+EAjpBsKEgWY3scvh28mYYlgzlVQaie0ABpQHA2eDnR9dggZ/z gheBTG00pD6ncQZDC39mo6+GmvW1QZJcclPMGKHcWbjqlR5GfBO6YjHvam39lQWURfsn c4SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UbK3ff7tkUPcHghAQTVeAf2fuJjuxHGQPDTK5XeMpGM=; b=kTcSdri3bIgJ5nt+EauDC4yCzwrZADqLVK6fXvVmFQmjztZ0iA1jtmAbyHIz/mD82h 4BShyPHmLb9vJqkhiSjY6a2+mE0KuOm8Ao1QhI6o+Aq+mO+FekZ1ahSvHl4uYQwjjWKO tZNlVB62JpecUm+qtam0OiV1fiTPAf5PvulxOGnFJ3LbQyikbRcZ9Kbphf6p8hdRtNit +OSUd8Ngg1eKNEoJ2TRoLdxGMM0nqD0iPEZk5bu/AFPQaDgm9MIcM8CZoG9nAmqrqskW pnQP7s7psBE8qoaULk8wb2FfCqhygPmh5WrVkJ7jK9TWD0eGITIZq0k6zDiWFizs49Eb FXJA== X-Gm-Message-State: AODbwcDWMwrKCr8kSQHEfqklS/hlh0LbsjILSg79RO2wNvubc997EVYd BYmwuoNUsfcuegqx5oMfPZfdafxong== X-Received: by 10.129.89.85 with SMTP id n82mr5416857ywb.94.1494432418833; Wed, 10 May 2017 09:06:58 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.20.214 with HTTP; Wed, 10 May 2017 09:06:58 -0700 (PDT) In-Reply-To: References: From: Alan Somers Date: Wed, 10 May 2017 10:06:58 -0600 X-Google-Sender-Auth: Vs6BCwVdZXxN8ZzO2SD0kiP1B1Y Message-ID: Subject: Re: hardware performance monitoring counters To: "Russell L. Carter" Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:07:00 -0000 On Wed, May 10, 2017 at 9:45 AM, Russell L. Carter wrote: > Greetings, > I'd like to use the PMC capabilities, but I seem to have > a misconfiguration: > > root@bruno> pmccontrol -l > pmccontrol: Initialization of the pmc(3) library failed: No such file or > directory > > In my kernel conf directory: > > root@bruno> grep -i pmc * > [...] > RLCBASE:options HWPMC_HOOKS # Necessary kernel hooks for > hwpmc(4) > [...] > > Both amd and intel systems have the same error on fresh 11/stable > amd64 systems. Mr. google turns up people having the same > problem, but no solutions. > > Does anyone know how I might fix this? > > Thanks, > Russell You need to "kldload hwpmc" first. -Alan From owner-freebsd-hackers@freebsd.org Wed May 10 16:14:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD4E0D67B40 for ; Wed, 10 May 2017 16:14:51 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from h2.pinyon.org (h2.pinyon.org [65.101.20.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7151CD7; Wed, 10 May 2017 16:14:51 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by h2.pinyon.org (Postfix, from userid 58) id 99F47214EB; Wed, 10 May 2017 09:14:50 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pinyon.org; s=DKIM; t=1494432890; bh=MATzRu3XwcSPLg+d6klBTqw4+u3lB6XftsWsz+gNpK4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=evRrb5/lky5+kGeSpKDlgQhV5gDKmKggMsS+K4Hmo8cJUfKBm87bqzXYGz0X2zdyf SEH5PQmqGGbwAJmCS7q+JcqR/3ZFFZpIPEYZAxxRJooIAGWt0dv7jQ05VFEcynTGad /M0vg8msnieg2KMHSwH+l5QJh3CMWrUFWzsUfBtU= X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on h2.n1.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from [10.0.10.15] (h1.pinyon.org [65.101.20.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by h2.pinyon.org (Postfix) with ESMTPSA id A976E214D2; Wed, 10 May 2017 09:14:49 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pinyon.org; s=DKIM; t=1494432889; bh=MATzRu3XwcSPLg+d6klBTqw4+u3lB6XftsWsz+gNpK4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Gz9DyEWLY7j6OO91/kXX8wZcCzKVYsdIRKoVlE3m5IDV3tJsCXna0+hrz+ajFl5cv QPTMUN+ll597V3xTY4plVxsO1ikXAB/KLrWM7ijQVOKLVTjOol01xFQR3J7bJr3/U4 ziUFSdv3UvXezkG8FuWuxDN7epb+omurnQJ5c/CY= Subject: Re: hardware performance monitoring counters To: Alan Somers Cc: "freebsd-hackers@freebsd.org" References: From: "Russell L. Carter" Message-ID: <096686ac-a4c8-af51-2bb6-452372b37910@pinyon.org> Date: Wed, 10 May 2017 09:14:49 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:14:51 -0000 On 05/10/17 09:06, Alan Somers wrote: > On Wed, May 10, 2017 at 9:45 AM, Russell L. Carter wrote: >> Greetings, >> I'd like to use the PMC capabilities, but I seem to have >> a misconfiguration: >> >> root@bruno> pmccontrol -l >> pmccontrol: Initialization of the pmc(3) library failed: No such file or >> directory >> >> In my kernel conf directory: >> >> root@bruno> grep -i pmc * >> [...] >> RLCBASE:options HWPMC_HOOKS # Necessary kernel hooks for >> hwpmc(4) >> [...] >> >> Both amd and intel systems have the same error on fresh 11/stable >> amd64 systems. Mr. google turns up people having the same >> problem, but no solutions. >> >> Does anyone know how I might fix this? >> >> Thanks, >> Russell > > You need to "kldload hwpmc" first. Perfect, thanks. Google should be able to find the answer now. Russell > -Alan > From owner-freebsd-hackers@freebsd.org Thu May 11 06:34:16 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B36BAD68F3B for ; Thu, 11 May 2017 06:34:16 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 723B719CE for ; Thu, 11 May 2017 06:34:15 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [78.47.166.52] (helo=sslproxy04.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1d8hfw-0000XL-KR; Thu, 11 May 2017 08:34:12 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy04.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d8hfw-0000dQ-Dm; Thu, 11 May 2017 08:34:12 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 862092A003F; Thu, 11 May 2017 08:34:39 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5AN-2kijCbIt; Thu, 11 May 2017 08:34:37 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 2EB672A160A; Thu, 11 May 2017 08:34:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FMaPn8ftCq6P; Thu, 11 May 2017 08:34:37 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 158D52A003F; Thu, 11 May 2017 08:34:37 +0200 (CEST) Subject: Re: Linux gen_pool allocator replacement? To: Konstantin Belousov References: <5912D448.5060201@embedded-brains.de> <20170510091946.GT1622@kib.kiev.ua> Cc: FreeBSD From: Sebastian Huber Message-ID: <591405E1.1000204@embedded-brains.de> Date: Thu, 11 May 2017 08:34:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20170510091946.GT1622@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23375/Wed May 10 23:03:12 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 06:34:16 -0000 On 10/05/17 11:19, Konstantin Belousov wrote: > On Wed, May 10, 2017 at 10:50:16AM +0200, Sebastian Huber wrote: >> Hello, >> >> I try currently to port a BSD licensed Linux network interface driver = to >> FreeBSD. This driver uses the gen_pool allocator >> >> http://elixir.free-electrons.com/linux/latest/source/include/linux/gen= alloc.h >> >> for example here >> >> https://github.com/torvalds/linux/blob/master/drivers/soc/fsl/qbman/qm= an.c#L2707 >> >> Does someone know if something similar exits in the FreeBSD kernel? I >> cannot use UMA since the pool management data must reside outside the >> managed memory area. One use case in this driver seems just to manage = a > I think you would get more useful answers if you explain what the > facility does. > >> range of integers, so no actual memory allocation. For this I could >> probably use UNR(9), but a general gen_pool allocator replacement woul= d >> be nice. > For an abstract resource allocator, look at vmem(9). It manages arbitr= ary > resources represented by ranges of integer values, you can use the rang= e > of size 1. > > There is no man page for vmem(9), but the interface is clearly explaine= d > in sys/vmem.h, and there is an article by Jeff Bonwick and Jonathan > Adams about vmem, describing the original Solaris facility. Thanks for the hint to vmem(9). There seems to be already a=20 driver-specific support using blist for gen_pool: https://github.com/freebsd/freebsd/blob/master/sys/dev/cxgb/ulp/iw_cxgb/i= w_cxgb_hal.h#L190 --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=E4ftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@freebsd.org Thu May 11 08:28:57 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06A29D6785F for ; Thu, 11 May 2017 08:28:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92ADB1B16 for ; Thu, 11 May 2017 08:28:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4B8Shmp084145 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 May 2017 11:28:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4B8Shmp084145 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4B8Sh6o084144; Thu, 11 May 2017 11:28:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 11 May 2017 11:28:43 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: FreeBSD Subject: Re: Linux gen_pool allocator replacement? Message-ID: <20170511082843.GU1622@kib.kiev.ua> References: <5912D448.5060201@embedded-brains.de> <20170510091946.GT1622@kib.kiev.ua> <591405E1.1000204@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <591405E1.1000204@embedded-brains.de> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 08:28:57 -0000 On Thu, May 11, 2017 at 08:34:09AM +0200, Sebastian Huber wrote: > Thanks for the hint to vmem(9). There seems to be already a > driver-specific support using blist for gen_pool: > > https://github.com/freebsd/freebsd/blob/master/sys/dev/cxgb/ulp/iw_cxgb/iw_cxgb_hal.h#L190 I see. Just a note, this is rather naive and lock-heavy comparing with the caching and streamlined vmem(9). OTOH, the code seems to be from the time when we did not have vmem(9) ported. From owner-freebsd-hackers@freebsd.org Fri May 12 21:26:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E432D6902C for ; Fri, 12 May 2017 21:26:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2CA992C7 for ; Fri, 12 May 2017 21:26:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4CLPI3N082246 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 12 May 2017 14:25:18 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4CLPIxl082245 for freebsd-hackers@freebsd.org; Fri, 12 May 2017 14:25:18 -0700 (PDT) (envelope-from sgk) Date: Fri, 12 May 2017 14:25:18 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: nm(1) -- what is 'r'? Message-ID: <20170512212518.GA82236@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 21:26:13 -0000 Compiled libm. Did 'nm catrig.o'. Found the following: 00000008 r pio2_lo 00000000 r tiny What is 'r' mean? nm(1) lacks a description. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Fri May 12 21:31:21 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 187D8D691B0 for ; Fri, 12 May 2017 21:31:21 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED9F979F for ; Fri, 12 May 2017 21:31:20 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6632c02c-375a-11e7-bfb5-0d159cd3c324 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 6632c02c-375a-11e7-bfb5-0d159cd3c324; Fri, 12 May 2017 21:31:46 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v4CLVCWR001834; Fri, 12 May 2017 15:31:12 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1494624672.59865.74.camel@freebsd.org> Subject: Re: nm(1) -- what is 'r'? From: Ian Lepore To: sgk@troutmask.apl.washington.edu, freebsd-hackers@freebsd.org Date: Fri, 12 May 2017 15:31:12 -0600 In-Reply-To: <20170512212518.GA82236@troutmask.apl.washington.edu> References: <20170512212518.GA82236@troutmask.apl.washington.edu> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 21:31:21 -0000 On Fri, 2017-05-12 at 14:25 -0700, Steve Kargl wrote: > Compiled libm.  Did 'nm catrig.o'.  Found the following: > > 00000008 r pio2_lo > 00000000 r tiny > > What is 'r' mean?  nm(1) lacks a description. > 'R' is for symbols in a read-only data section, and when it's lowercase that means it's a local symbol (all of which is in nm(1) but easy to overlook on a quick skim). -- Ian From owner-freebsd-hackers@freebsd.org Fri May 12 21:37:57 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF0DAD694FD for ; Fri, 12 May 2017 21:37:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 945B9C8C; Fri, 12 May 2017 21:37:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4CLbu8h082471 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 May 2017 14:37:56 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4CLbucT082470; Fri, 12 May 2017 14:37:56 -0700 (PDT) (envelope-from sgk) Date: Fri, 12 May 2017 14:37:56 -0700 From: Steve Kargl To: Ian Lepore Cc: freebsd-hackers@freebsd.org Subject: Re: nm(1) -- what is 'r'? Message-ID: <20170512213756.GB82390@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170512212518.GA82236@troutmask.apl.washington.edu> <1494624672.59865.74.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1494624672.59865.74.camel@freebsd.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 21:37:57 -0000 On Fri, May 12, 2017 at 03:31:12PM -0600, Ian Lepore wrote: > On Fri, 2017-05-12 at 14:25 -0700, Steve Kargl wrote: > > Compiled libm.  Did 'nm catrig.o'.  Found the following: > > > > 00000008 r pio2_lo > > 00000000 r tiny > > > > What is 'r' mean?  nm(1) lacks a description. > > > > 'R' is for symbols in a read-only data section, and when it's lowercase > that means it's a local symbol (all of which is in nm(1) but easy to > overlook on a quick skim). > Thanks. It is indeed very easy to miss. It seems elftoolchain's nm.1 lacks a description of 'r' and the lowercase/uppercase convention. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Fri May 12 21:56:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42F02D69E2F; Fri, 12 May 2017 21:56:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FAE088E; Fri, 12 May 2017 21:56:55 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4CLusWo082601 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 May 2017 14:56:54 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4CLusWG082600; Fri, 12 May 2017 14:56:54 -0700 (PDT) (envelope-from sgk) Date: Fri, 12 May 2017 14:56:54 -0700 From: Steve Kargl To: numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: catrig[fl].c and inexact Message-ID: <20170512215654.GA82545@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 21:56:58 -0000 So, I've been making improvements to my implementations of the half-cycle trig functions. In doing so, I decide to add WARNS=2 to msun/Makefile. clang 4.0.0 dies with an error about an unused variable in raise_inexact() from catrig[fl].c. /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:195:2: error: unused variable 'junk' [-Werror,-Wunused-variable] raise_inexact(); ^ /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:56:45: note: expanded from macro 'raise_inexact' #define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) ^ Grepping catrig.o for the variable 'junk' suggests that 'junk' is optimized out (with at least -O2). A quick and dirty patch to achieve the intent of the original code follows. It would be nice if some would like to commit the patch. Of course, you may want to wait for Bruce to review the diff. Index: src/catrig.c =================================================================== --- src/catrig.c (revision 1935) +++ src/catrig.c (working copy) @@ -37,7 +37,7 @@ __FBSDID("$FreeBSD: head/lib/msun/src/catrig.c 313863 #define isinf(x) (fabs(x) == INFINITY) #undef isnan #define isnan(x) ((x) != (x)) -#define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) +#define raise_inexact(x) do { (x) = 1 + tiny; } while(0) #undef signbit #define signbit(x) (__builtin_signbit(x)) @@ -315,7 +315,7 @@ casinh(double complex z) return (z); /* All remaining cases are inexact. */ - raise_inexact(); + raise_inexact(new_y); if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) return (z); @@ -400,7 +400,7 @@ cacos(double complex z) return (CMPLX(0, -y)); /* All remaining cases are inexact. */ - raise_inexact(); + raise_inexact(new_x); if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) return (CMPLX(pio2_hi - (x - pio2_lo), -y)); @@ -607,7 +607,7 @@ catanh(double complex z) * inexact, but this is the only only that needs to do it * explicitly. */ - raise_inexact(); + raise_inexact(ax); return (z); } Index: src/catrigf.c =================================================================== --- src/catrigf.c (revision 1935) +++ src/catrigf.c (working copy) @@ -51,7 +51,7 @@ __FBSDID("$FreeBSD: head/lib/msun/src/catrigf.c 275819 #define isinf(x) (fabsf(x) == INFINITY) #undef isnan #define isnan(x) ((x) != (x)) -#define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) +#define raise_inexact(x) do { (x) = 1 + tiny; } while(0) #undef signbit #define signbit(x) (__builtin_signbitf(x)) @@ -176,7 +176,7 @@ casinhf(float complex z) if (x == 0 && y == 0) return (z); - raise_inexact(); + raise_inexact(new_y); if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) return (z); @@ -234,7 +234,7 @@ cacosf(float complex z) if (x == 1 && y == 0) return (CMPLXF(0, -y)); - raise_inexact(); + raise_inexact(new_x); if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) return (CMPLXF(pio2_hi - (x - pio2_lo), -y)); @@ -365,7 +365,7 @@ catanhf(float complex z) copysignf(pio2_hi + pio2_lo, y))); if (ax < SQRT_3_EPSILON / 2 && ay < SQRT_3_EPSILON / 2) { - raise_inexact(); + raise_inexact(ax); return (z); } Index: src/catrigl.c =================================================================== --- src/catrigl.c (revision 1935) +++ src/catrigl.c (working copy) @@ -53,7 +53,7 @@ __FBSDID("$FreeBSD: head/lib/msun/src/catrigl.c 313761 #define isinf(x) (fabsl(x) == INFINITY) #undef isnan #define isnan(x) ((x) != (x)) -#define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) +#define raise_inexact(x) do { (x) = 1 + tiny; } while(0) #undef signbit #define signbit(x) (__builtin_signbitl(x)) @@ -192,7 +192,7 @@ casinhl(long double complex z) if (x == 0 && y == 0) return (z); - raise_inexact(); + raise_inexact(new_y); if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) return (z); @@ -251,7 +251,7 @@ cacosl(long double complex z) if (x == 1 && y == 0) return (CMPLXL(0, -y)); - raise_inexact(); + raise_inexact(new_x); if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) return (CMPLXL(pio2_hi - (x - pio2_lo), -y)); @@ -383,7 +383,7 @@ catanhl(long double complex z) copysignl(pio2_hi + pio2_lo, y))); if (ax < SQRT_3_EPSILON / 2 && ay < SQRT_3_EPSILON / 2) { - raise_inexact(); + raise_inexact(ax); return (z); } -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Fri May 12 23:16:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78B27D6A309 for ; Fri, 12 May 2017 23:16:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 52BA51EED; Fri, 12 May 2017 23:16:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4CNGwYU083007 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 May 2017 16:16:58 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4CNGwvY083006; Fri, 12 May 2017 16:16:58 -0700 (PDT) (envelope-from sgk) Date: Fri, 12 May 2017 16:16:58 -0700 From: Steve Kargl To: Ian Lepore Cc: freebsd-hackers@freebsd.org Subject: Re: nm(1) -- what is 'r'? Message-ID: <20170512231658.GA82997@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170512212518.GA82236@troutmask.apl.washington.edu> <1494624672.59865.74.camel@freebsd.org> <20170512213756.GB82390@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170512213756.GB82390@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 23:16:59 -0000 On Fri, May 12, 2017 at 02:37:56PM -0700, Steve Kargl wrote: > On Fri, May 12, 2017 at 03:31:12PM -0600, Ian Lepore wrote: > > On Fri, 2017-05-12 at 14:25 -0700, Steve Kargl wrote: > > > Compiled libm.  Did 'nm catrig.o'.  Found the following: > > > > > > 00000008 r pio2_lo > > > 00000000 r tiny > > > > > > What is 'r' mean?  nm(1) lacks a description. > > > > > > > 'R' is for symbols in a read-only data section, and when it's lowercase > > that means it's a local symbol (all of which is in nm(1) but easy to > > overlook on a quick skim). > > > > Thanks. It is indeed very easy to miss. It seems elftoolchain's > nm.1 lacks a description of 'r' and the lowercase/uppercase convention. > This is now in bugzilla. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219245 It should probably go upstream to Elftoolchain. I, however, did not find a reporting mechanism. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat May 13 01:05:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AB23D69B86 for ; Sat, 13 May 2017 01:05:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 315A1109B for ; Sat, 13 May 2017 01:05:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4D14x0d083407 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 12 May 2017 18:05:00 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4D14xbx083406 for freebsd-hackers@freebsd.org; Fri, 12 May 2017 18:04:59 -0700 (PDT) (envelope-from sgk) Date: Fri, 12 May 2017 18:04:59 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: mutex owned? Message-ID: <20170513010459.GA83399@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 01:05:01 -0000 So, after 6 to 8 hours of building libreoffice, I run into this [CUT] sw_odfimport Abort trap (core dumped) OK (1) Fatal error 'mutex 0x2beaa340 own 0x189be is on list 0x69004c 0x74006e' at line 153 in file /mnt/src/lib/libthr/thread/thr_mutex.c (errno = 0) No core file identified in directory /usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/workdir/CppunitTest/dbaccess_dialog_save.test.core To show backtraces for crashes during test execution, enable core files with: ulimit -c unlimited Error: a unit test failed, please do one of: make CppunitTest_dbaccess_dialog_save CPPUNITTRACE="gdb --args" # for interactive debugging on Linux make CppunitTest_dbaccess_dialog_save VALGRIND=memcheck # for memory checking make CppunitTest_dbaccess_dialog_save DEBUGCPPUNIT=TRUE # for exception catching gmake[3]: *** [/usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/solenv/gbuild/CppunitTest.mk:100: /usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/workdir/CppunitTest/dbaccess_dialog_save.test] Error 1 Is there a known issue with libthr on i686? -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat May 13 01:07:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E97F5D69D8A for ; Sat, 13 May 2017 01:07:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D10E0129B for ; Sat, 13 May 2017 01:07:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4D17pL0083445 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 12 May 2017 18:07:51 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4D17pWV083444 for freebsd-hackers@freebsd.org; Fri, 12 May 2017 18:07:51 -0700 (PDT) (envelope-from sgk) Date: Fri, 12 May 2017 18:07:51 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: Re: mutex owned? Message-ID: <20170513010751.GA83437@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170513010459.GA83399@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170513010459.GA83399@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 01:07:52 -0000 On Fri, May 12, 2017 at 06:04:59PM -0700, Steve Kargl wrote: > So, after 6 to 8 hours of building libreoffice, I run into this > > [CUT] sw_odfimport > Abort trap (core dumped) > OK (1) > Fatal error 'mutex 0x2beaa340 own 0x189be is on list 0x69004c 0x74006e' at line 153 in file /mnt/src/lib/libthr/thread/thr_mutex.c (errno = 0) > > No core file identified in directory /usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/workdir/CppunitTest/dbaccess_dialog_save.test.core > To show backtraces for crashes during test execution, > enable core files with: > > ulimit -c unlimited > > > Error: a unit test failed, please do one of: > make CppunitTest_dbaccess_dialog_save CPPUNITTRACE="gdb --args" > # for interactive debugging on Linux > make CppunitTest_dbaccess_dialog_save VALGRIND=memcheck > # for memory checking > make CppunitTest_dbaccess_dialog_save DEBUGCPPUNIT=TRUE > # for exception catching > > gmake[3]: *** [/usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/solenv/gbuild/CppunitTest.mk:100: /usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/workdir/CppunitTest/dbaccess_dialog_save.test] Error 1 > > Is there a known issue with libthr on i686? > Forgot to mention that this is a recent FreeBSD-current. FreeBSD laptop-kargl 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r317842: Sat May 6 07:35:30 PDT 2017 kargl@laptop-kargl:/mnt/obj/mnt/src/sys/MOBILE i386 -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat May 13 02:02:32 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE746D6AD74; Sat, 13 May 2017 02:02:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3A11F23; Sat, 13 May 2017 02:02:31 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 80712D654C9; Sat, 13 May 2017 11:35:54 +1000 (AEST) Date: Sat, 13 May 2017 11:35:49 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: catrig[fl].c and inexact In-Reply-To: <20170512215654.GA82545@troutmask.apl.washington.edu> Message-ID: <20170513103208.M845@besplex.bde.org> References: <20170512215654.GA82545@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=WvBbCZXv c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=0K0djoc-qRL17_fbz0IA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Sat, 13 May 2017 04:54:29 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 02:02:32 -0000 On Fri, 12 May 2017, Steve Kargl wrote: > So, I've been making improvements to my implementations of > the half-cycle trig functions. In doing so, I decide to > add WARNS=2 to msun/Makefile. clang 4.0.0 dies with an > error about an unused variable in raise_inexact() from > catrig[fl].c. > > /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:195:2: error: unused variable > 'junk' [-Werror,-Wunused-variable] > raise_inexact(); > ^ > /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:56:45: note: expanded from > macro 'raise_inexact' > #define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) > ^ > Grepping catrig.o for the variable 'junk' suggests that 'junk' is > optimized out (with at least -O2). Just another bug in clang. Volatile variables cannot be optimized out (if they are accessed). > A quick and dirty patch to achieve the intent of the original > code follows. It would be nice if some would like to commit > the patch. Of course, you may want to wait for Bruce to > review the diff. > > Index: src/catrig.c > =================================================================== > --- src/catrig.c (revision 1935) > +++ src/catrig.c (working copy) > @@ -37,7 +37,7 @@ __FBSDID("$FreeBSD: head/lib/msun/src/catrig.c 313863 > #define isinf(x) (fabs(x) == INFINITY) > #undef isnan > #define isnan(x) ((x) != (x)) > -#define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) > +#define raise_inexact(x) do { (x) = 1 + tiny; } while(0) > #undef signbit > #define signbit(x) (__builtin_signbit(x)) > > @@ -315,7 +315,7 @@ casinh(double complex z) > return (z); > > /* All remaining cases are inexact. */ > - raise_inexact(); > + raise_inexact(new_y); > > if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) > return (z); Now it doesn't take compiler bugs to optimize it out, since new_y is not volatile, and a good compiler would optimize it out in all cases. new_y is obviously unused before the early returns, so it doesn't need to be evalated before the returns as far as the compiler can see. Later, new_y is initialized indirectly, and the compiler can see that too (not so easily, so it can see that raise_inexact() has no effect except possibly for its side effect of raising inexact for 1 + tiny. The change might defeat the intent of the original code in another way. 'junk' is intentionally independent of other variables, so that there are no dependencies on it. If the compiler doesn't optimize away the assignment to new_y, then it is probably because it doesn't see that the assignment is dead, so there is a dependency. Actually, we want the variable 'junk' to be optimized away. We only want the side effect of evaluating 1 + tiny. Compilers have bugs evaluating expressions like 1 + tiny, tiny*tiny and huge*huge, and we use assignments of the result to volatile variables in tens if not hundreds of places to try to work around compiler bugs. If that doesn't work here, then all the other places are probably broken too. The other places mostly use a static volatile, while this uses an auto volatile. 'tiny' is also volatile, as required for the standard magic. I planned to fix all this magic using macros like raise_inexact(). Another subtety in the macro is that variable is float instead of double to possibly allow optimizations. Since the variable shouldn't be optimized away, it will waste sizeof(var) for each use of the macro. A file scope variable would work better here, but the macro is written to be self-contained to make it easier to use. The change also defeats that. Whether not evaluating 1 + tiny at compile time is a compiler bug is delicate. We don't have any C99 compilers yet, since gcc and clang don't support #pragma FENV_ACCESS ON/OFF. The pragma should be set to ON before the magic accesses, but we don't do that because it would be a lot of churn and we know that the pragma doesn't work. We more or less depend on the default state of the pragma being ON, but in gcc-4.2.1 it is documented as being OFF unless compiled with -frounding-math when it is documented as being ON, and for clang it is undocumented. -frounding-math is too inefficient to use by default, and another bug in clang is that it is not even supported. With macro or at least inline wrappers, the #pragma should only be needed in a few places. clang-3.9.0 seems to be only partly broken here. Volatile works correctly for v = huge*huge and also for v = 1+tiny provided v is static instead of auto. It also works to declare 'junk' as __unused. The following don't work with either clang-3.9.0 or gcc-4.2.1: - declaring 'junk' as __used (syntax error) - the expression 1+tiny not assigned to anything, or 1+tiny assigned to an __unused non-volatile variable. This gives the weird code of loading 'tiny' (because the compiler handles read accesses to volatile variables correctly), but not adding 1 (because the compiler doesn't know that adding 1 has a side effect, or is optimizing for FENV_ACCESS OFF). The following is documented to not work with gcc-4.2.1: - #pragma FENV_ACCESS ON. clang handles this correctly by warning that this is unsupported, but this makes it even more unusable. gcc-4.2.1 doesn't warn, so it is hard to tell if it worked. Bruce From owner-freebsd-hackers@freebsd.org Sat May 13 06:08:05 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13B43D6A5A3; Sat, 13 May 2017 06:08:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F2C3218B2; Sat, 13 May 2017 06:08:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4D6839N084468 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 May 2017 23:08:03 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4D683TW084467; Fri, 12 May 2017 23:08:03 -0700 (PDT) (envelope-from sgk) Date: Fri, 12 May 2017 23:08:03 -0700 From: Steve Kargl To: Bruce Evans Cc: numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: catrig[fl].c and inexact Message-ID: <20170513060803.GA84399@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170513103208.M845@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 06:08:05 -0000 On Sat, May 13, 2017 at 11:35:49AM +1000, Bruce Evans wrote: > On Fri, 12 May 2017, Steve Kargl wrote: > > > So, I've been making improvements to my implementations of > > the half-cycle trig functions. In doing so, I decide to > > add WARNS=2 to msun/Makefile. clang 4.0.0 dies with an > > error about an unused variable in raise_inexact() from > > catrig[fl].c. > > > > /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:195:2: error: unused variable > > 'junk' [-Werror,-Wunused-variable] > > raise_inexact(); > > ^ > > /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:56:45: note: expanded from > > macro 'raise_inexact' > > #define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) > > ^ > > Grepping catrig.o for the variable 'junk' suggests that 'junk' is > > optimized out (with at least -O2). > > Just another bug in clang. Volatile variables cannot be optimized out > (if they are accessed). Does this depend on scope? 'junk' is local to the do {...} while(0); construct. Can a compiler completely eliminate a do-nothing scoping unit? I don't know C well enough to know. I do know what I have observed in clang. > > A quick and dirty patch to achieve the intent of the original > > code follows. It would be nice if some would like to commit > > the patch. Of course, you may want to wait for Bruce to > > review the diff. > > > > Index: src/catrig.c > > =================================================================== > > --- src/catrig.c (revision 1935) > > +++ src/catrig.c (working copy) > > @@ -37,7 +37,7 @@ __FBSDID("$FreeBSD: head/lib/msun/src/catrig.c 313863 > > #define isinf(x) (fabs(x) == INFINITY) > > #undef isnan > > #define isnan(x) ((x) != (x)) > > -#define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) > > +#define raise_inexact(x) do { (x) = 1 + tiny; } while(0) > > #undef signbit > > #define signbit(x) (__builtin_signbit(x)) > > > > @@ -315,7 +315,7 @@ casinh(double complex z) > > return (z); > > > > /* All remaining cases are inexact. */ > > - raise_inexact(); > > + raise_inexact(new_y); > > > > if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) > > return (z); > > Now it doesn't take compiler bugs to optimize it out, since new_y is not > volatile, and a good compiler would optimize it out in all cases. I've yet to find a good compiler. They all seem to have bugs. > new_y > is obviously unused before the early returns, so it doesn't need to be > evalated before the returns as far as the compiler can see. Later, > new_y is initialized indirectly, and the compiler can see that too (not > so easily, so it can see that raise_inexact() has no effect except possibly > for its side effect of raising inexact for 1 + tiny. The later call passes the address of new_y to the routine. How can the compiler short of inlining the called routine know that the value assigned to new_y isn't used? > The change might defeat the intent of the original code in another way. > 'junk' is intentionally independent of other variables, so that there are > no dependencies on it. If the compiler doesn't optimize away the assignment > to new_y, then it is probably because it doesn't see that the assignment is > dead, so there is a dependency. It may defeat the intent of the original code, but it seems that the original code provokes undefined behavior. > Actually, we want the variable 'junk' to be optimized away. We only want > the side effect of evaluating 1 + tiny. Compilers have bugs evaluating > expressions like 1 + tiny, tiny*tiny and huge*huge, and we use assignments > of the result to volatile variables in tens if not hundreds of places to > try to work around compiler bugs. If that doesn't work here, then all the > other places are probably broken too. The other places mostly use a static > volatile, while this uses an auto volatile. 'tiny' is also volatile, as > required for the standard magic. I planned to fix all this magic using > macros like raise_inexact(). If you plan to fix the magic with raise_inexact, then please test with a suite of compilers. AFAICT, clang is optimizing out the code. I haven't written a testcase to demonstrate this as I have other irons in the fire. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat May 13 10:40:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6698AD696D5 for ; Sat, 13 May 2017 10:40:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-8.reflexion.net [208.70.210.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CB2511AD for ; Sat, 13 May 2017 10:40:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2041 invoked from network); 13 May 2017 10:40:41 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 May 2017 10:40:41 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 13 May 2017 06:40:41 -0400 (EDT) Received: (qmail 18264 invoked from network); 13 May 2017 10:40:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 May 2017 10:40:40 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 29F9BEC8697; Sat, 13 May 2017 03:40:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: catrig[fl].c and inexact From: Mark Millard In-Reply-To: <20170513060803.GA84399@troutmask.apl.washington.edu> Date: Sat, 13 May 2017 03:40:39 -0700 Cc: Bruce Evans , freebsd-hackers@freebsd.org, numerics@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> <20170513060803.GA84399@troutmask.apl.washington.edu> To: sgk@troutmask.apl.washington.edu X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 10:40:43 -0000 On 2017-May-12, at 11:08 PM, Steve Kargl wrote: > On Sat, May 13, 2017 at 11:35:49AM +1000, Bruce Evans wrote: >> On Fri, 12 May 2017, Steve Kargl wrote: >>=20 >>> So, I've been making improvements to my implementations of >>> the half-cycle trig functions. In doing so, I decide to >>> add WARNS=3D2 to msun/Makefile. clang 4.0.0 dies with an >>> error about an unused variable in raise_inexact() from >>> catrig[fl].c. >>>=20 >>> /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:195:2: error: = unused variable >>> 'junk' [-Werror,-Wunused-variable] >>> raise_inexact(); >>> ^ >>> /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:56:45: note: = expanded from >>> macro 'raise_inexact' >>> #define raise_inexact() do { volatile float junk =3D 1 + tiny; } = while(0) >>> ^ >>> Grepping catrig.o for the variable 'junk' suggests that 'junk' is >>> optimized out (with at least -O2). >>=20 >> Just another bug in clang. Volatile variables cannot be optimized = out >> (if they are accessed). >=20 > Does this depend on scope? 'junk' is local to the do {...} while(0); > construct. Can a compiler completely eliminate a do-nothing scoping > unit? I don't know C well enough to know. I do know what I have > observed in clang. [This note ignores other standards than C99/C11 that might place other constraints. And I've done no checking of compiler results, I've just looked at a couple of the C standards.] Note: I've not looking to tiny's declaration. It may contribute in a way not covered below. Unfortunately the declarator in an init-declarator that has an initializer is not part of an expression. The rules for volatile are tied to uses in expressions, not to the declarator. (Which is a hole in the language definition as far as I can tell.) There is one part of the wording that might mitigate this, tied to a full declarator having a sequence point at its end despite the declarator itself not being an expression, even if its initializer is one. There is another wording detail that might as well. Still, overall it would seem safer to be sure there is an expression that references the volatile object, not having only its declarator. But I would not take even that as a guarantee under the C standards. It may seem a silly difference but: do { volatile float junk=3D1; junk+=3Dtiny; } while(0) may well be a better way of writing the "must evaluate" part of the intent simply because junk is used in an expression. Also it has both read and write access, so is a little more "used". The sequence point before the assignment can help avoid compile-time evaluation as well. Details if you care. . . I used the C99 and C11 definitions here, I reference C11 section numbering but C99 agrees as I remember. 5.1.2.3 Program execution says: "Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression may produce side effects." Note that raising inexact does not fit in the definition of side effect as far as I can tell. So a compiler need not consider such a thing for side-effect issues if I understand right. [C11 specific wording:] "The presence of a sequence point between the evaluations of expressions A and B implies that every value computation and side effect associated with A is sequenced before every value compuation and side effect associated with B." [C99 is similar but is before the detailed "sequenced before" definition.] "An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object)." Can a accessing a volatile object ever be classified as having "no needed side effects"? More on this later. [Remember what "side effect" excludes, as noted earlier. So some consequences need not be considered by the compiler, all in the name of optimizations.] 6.7.3 Type Qualifiers says: "An object that has volatile-qualified type . . . Therefore any expression referring to such as object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. What constitutes an access to an object that has volatile-qualified type is implementation-defined." This part is mixed: what the sequence point wording giveth the last sentence taketh away. (More later.) It also says in a note (134): "A volatile declaration may be used to describe an object corresponding to a memory-mapped input/output port or an object accessed by an asynchronously interrupting function. Actions on objects so declared shall, not be "optimized out" by an implementation or reordered except as permitted by the rules for evaluating expressions." Since rules for evaluating expressions are not rules for declarators (vs. initializers), this could be read as not allowing the "optimize out". (But the abstract machine's description is not explicit about declarators for such issues.) The C99 Rationale: The C99 Rationale was explicit about static volatile for a memory mapped I/O register, static const volatile for a memory mapped input port, const volatile and volatile for variables shared across processes. To some extent this identifies examples of contexts with "needed side effects" that have hardware details to take into account. For taking into account hardware details: ". . . Whatever decision are adopted on such issues must be documented, as volatile access is implementation-defined". For volatile use with no explicitly identified hardware details: volatile would appear to be no more than a potential hint for such a context, not an effective requirement. The implementation-defined status could allow lack of access. Overall, based on what I see in the C99 and C11 language definitions, I'd not be willing to declare clang wrong (if it did optimize out junk), even with my alternative formulation. C does not have an explicit Principle of Least Astonishment as a official guideline to its interpretation and the rules are very biased to allowing so-called optimizations. "junk" does not fit with being shared across processes (for example its address is not handed to anything) and is not static or even global. There is no known type of potential context for specific hardware details that would need to be taken into account for junk. That in turn leaves open not accessing it at all as far as I can tell. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat May 13 02:05:53 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B23B5D6AF88; Sat, 13 May 2017 02:05:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5D7B6; Sat, 13 May 2017 02:05:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 847803CB4B9; Sat, 13 May 2017 11:44:45 +1000 (AEST) Date: Sat, 13 May 2017 11:44:41 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans cc: Steve Kargl , numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: catrig[fl].c and inexact In-Reply-To: <20170513103208.M845@besplex.bde.org> Message-ID: <20170513113852.M1045@besplex.bde.org> References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=UZVNq-k9JjFpydrfkmMA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Sat, 13 May 2017 10:57:19 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 02:05:53 -0000 On Sat, 13 May 2017, Bruce Evans wrote: > clang-3.9.0 seems to be only partly broken here. Volatile works correctly > for v = huge*huge and also for v = 1+tiny provided v is static instead of > auto. It also works to declare 'junk' as __unused. PS: only __unused on an auto volatile variable gives the intended but not quite wanted behaviour, by reminding the compiler than assignments to volatile variables are used, by spelling 'used' as __unused. This results in assigning to a variable on the stack in most cases, so there is no wastage of static space. Normal FP operations like this are usually the fastest way to set FP exception flags (50-100 times faster than an fenv access on i386). The only sub-optimal part is assigning the result to memory. Bruce From owner-freebsd-hackers@freebsd.org Sat May 13 11:01:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0192CD6A24E; Sat, 13 May 2017 11:01:15 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD736A95; Sat, 13 May 2017 11:01:14 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:470:7a58::a8c1:a7f4:edbc:3331] (unknown [IPv6:2001:470:7a58:0:a8c1:a7f4:edbc:3331]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5AF543FD73; Sat, 13 May 2017 13:01:12 +0200 (CEST) From: Dimitry Andric Message-Id: <42D3F536-42D7-4097-A500-0EF939584592@andric.com> Content-Type: multipart/signed; boundary="Apple-Mail=_3FD2EBD2-6E86-4877-858B-D4C2722775DB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: catrig[fl].c and inexact Date: Sat, 13 May 2017 13:00:59 +0200 In-Reply-To: <20170512215654.GA82545@troutmask.apl.washington.edu> Cc: numerics@freebsd.org, freebsd-hackers@freebsd.org To: sgk@troutmask.apl.washington.edu References: <20170512215654.GA82545@troutmask.apl.washington.edu> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 11:01:15 -0000 --Apple-Mail=_3FD2EBD2-6E86-4877-858B-D4C2722775DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 May 2017, at 23:56, Steve Kargl = wrote: >=20 > So, I've been making improvements to my implementations of > the half-cycle trig functions. In doing so, I decide to > add WARNS=3D2 to msun/Makefile. clang 4.0.0 dies with an > error about an unused variable in raise_inexact() from > catrig[fl].c. >=20 > /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:195:2: error: = unused variable > 'junk' [-Werror,-Wunused-variable] > raise_inexact(); > ^ > /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:56:45: note: = expanded from > macro 'raise_inexact' > #define raise_inexact() do { volatile float junk =3D 1 + tiny; } = while(0) > ^ > Grepping catrig.o for the variable 'junk' suggests that 'junk' is > optimized out (with at least -O2). As far as I can see, this is not the case. The simplest reduction is this: static const volatile float tiny =3D 0x1p-100; void f(void) { volatile float junk =3D 1 + tiny; } For i386-freebsd, this results in the following (boilerplate left out): $ clang-4.0.0 -target i386-freebsd -O2 -S vol1.c -o - [...] pushl %ebp movl %esp, %ebp pushl %eax fld1 fadds tiny fstps -4(%ebp) addl $4, %esp popl %ebp retl [...] tiny: .long 226492416 # float 7.88860905E-31 For amd64-freebsd: $ clang-4.0.0 -target amd64-freebsd -O2 -S vol1.c -o - [...] .LCPI0_0: .long 1065353216 # float 1 [...] pushq %rbp movq %rsp, %rbp movss tiny(%rip), %xmm0 # xmm0 =3D mem[0],zero,zero,zero addss .LCPI0_0(%rip), %xmm0 movss %xmm0, -4(%rbp) popq %rbp retq [...] tiny: .long 226492416 # float 7.88860905E-31 I also tried -O3, but it doesn't change the result. -Dimitry --Apple-Mail=_3FD2EBD2-6E86-4877-858B-D4C2722775DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlkW53gACgkQsF6jCi4glqPkNACfTDp+YbDQinSkExo64JsidEmj bWMAnA3VM6qYzUFY/5BpESn9zX3x2nxk =NqYy -----END PGP SIGNATURE----- --Apple-Mail=_3FD2EBD2-6E86-4877-858B-D4C2722775DB-- From owner-freebsd-hackers@freebsd.org Sat May 13 12:38:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59B5CD6B773 for ; Sat, 13 May 2017 12:38:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5992998 for ; Sat, 13 May 2017 12:38:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v4DCcbIS076241 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 May 2017 15:38:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v4DCcbIS076241 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v4DCcb9v076240; Sat, 13 May 2017 15:38:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 May 2017 15:38:37 +0300 From: Konstantin Belousov To: Steve Kargl Cc: freebsd-hackers@freebsd.org Subject: Re: mutex owned? Message-ID: <20170513123836.GY1622@kib.kiev.ua> References: <20170513010459.GA83399@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170513010459.GA83399@troutmask.apl.washington.edu> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 12:38:44 -0000 On Fri, May 12, 2017 at 06:04:59PM -0700, Steve Kargl wrote: > So, after 6 to 8 hours of building libreoffice, I run into this > > [CUT] sw_odfimport > Abort trap (core dumped) > OK (1) > Fatal error 'mutex 0x2beaa340 own 0x189be is on list 0x69004c 0x74006e' at line 153 in file /mnt/src/lib/libthr/thread/thr_mutex.c (errno = 0) > > No core file identified in directory /usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/workdir/CppunitTest/dbaccess_dialog_save.test.core > To show backtraces for crashes during test execution, > enable core files with: > > ulimit -c unlimited > > > Error: a unit test failed, please do one of: > make CppunitTest_dbaccess_dialog_save CPPUNITTRACE="gdb --args" > # for interactive debugging on Linux > make CppunitTest_dbaccess_dialog_save VALGRIND=memcheck > # for memory checking > make CppunitTest_dbaccess_dialog_save DEBUGCPPUNIT=TRUE > # for exception catching > > gmake[3]: *** [/usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/solenv/gbuild/CppunitTest.mk:100: /usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/workdir/CppunitTest/dbaccess_dialog_save.test] Error 1 > > Is there a known issue with libthr on i686? I am not aware. Please ensure that your libthr and libc are built with debugging symbols (default on HEAD), obtain core dump and show me the backtrace, for the start. From owner-freebsd-hackers@freebsd.org Sat May 13 13:08:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 577DAD6A37A; Sat, 13 May 2017 13:08:37 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E16B51BE1; Sat, 13 May 2017 13:08:36 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:470:7a58::a8c1:a7f4:edbc:3331] (unknown [IPv6:2001:470:7a58:0:a8c1:a7f4:edbc:3331]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8EF363FD81; Sat, 13 May 2017 15:08:33 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4FBC88C3-4C7E-4D97-8BD0-773DBE95BCD3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: catrig[fl].c and inexact Date: Sat, 13 May 2017 15:08:26 +0200 In-Reply-To: <20170513060803.GA84399@troutmask.apl.washington.edu> Cc: Bruce Evans , freebsd-hackers@freebsd.org, numerics@freebsd.org To: sgk@troutmask.apl.washington.edu References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> <20170513060803.GA84399@troutmask.apl.washington.edu> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 13:08:37 -0000 --Apple-Mail=_4FBC88C3-4C7E-4D97-8BD0-773DBE95BCD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 May 2017, at 08:08, Steve Kargl = wrote: >=20 > On Sat, May 13, 2017 at 11:35:49AM +1000, Bruce Evans wrote: >> On Fri, 12 May 2017, Steve Kargl wrote: ... >> required for the standard magic. I planned to fix all this magic = using >> macros like raise_inexact(). >=20 > If you plan to fix the magic with raise_inexact, then please > test with a suite of compilers. AFAICT, clang is optimizing > out the code. I haven't written a testcase to demonstrate this > as I have other irons in the fire. Using the full catrig.c and -O3, I tried gcc 4.2.1, 4.7.4, 4.8.5, 4.9.4, 5.4.0, 6.3.0 and 7.0.1, in addition to clang 3.4.1, 3.8.0, 3.9.1, 4.0.0 and 5.0.0. All versions of gcc produced something similar to the following for i386: # /usr/src/lib/msun/src/catrig.c:314: if (x =3D=3D 0 && y =3D=3D 0) .loc 1 314 0 fldz fucom %st(3) # fnstsw %ax # tmp262 sahf setne %al #, tmp270 setnp %dl #, tmp259 subl $1, %eax #, tmp270 testb %al, %dl # tmp270, tmp259 je .L176 #, fucomp %st(1) # fnstsw %ax # tmp281 sahf setne %al #, tmp289 setnp %dl #, tmp278 subl $1, %eax #, tmp289 testb %al, %dl # tmp289, tmp278 je .L37 #, fstp %st(3) # fstp %st(0) # jmp .L153 # [...] .L176: fstp %st(0) # .L37: .LBB25: # /usr/src/lib/msun/src/catrig.c:318: raise_inexact(); flds tiny # tiny fadds .LC2 # fstps 120(%esp) # junk and for amd64: # /usr/src/lib/msun/src/catrig.c:314: if (x =3D=3D 0 && y =3D=3D 0) .loc 1 314 0 pxor %xmm7, %xmm7 # tmp386 ucomisd %xmm7, %xmm3 # tmp386, z setnp %dl #, tmp258 cmovne %eax, %edx # tmp258,, tmp207, tmp254 testb %dl, %dl # tmp254 je .L34 #, ucomisd %xmm7, %xmm1 # tmp386, z setnp %dl #, tmp266 cmove %edx, %eax # tmp266,, tmp262 testb %al, %al # tmp262 je .L34 #, [...] .L34: .LBB33: # /usr/src/lib/msun/src/catrig.c:318: raise_inexact(); movss tiny(%rip), %xmm0 # tiny, tiny.0_28 addss .LC13(%rip), %xmm0 #, _29 movss %xmm0, 188(%rsp) # _29, junk All versions of clang produced something similar to the following for i386: .loc 1 314 8 is_stmt 1 # = /usr/src/lib/msun/src/catrig.c:314:8 fldz .loc 1 314 13 is_stmt 0 # = /usr/src/lib/msun/src/catrig.c:314:13 fxch %st(1) fucom %st(1) fnstsw %ax sahf jne .LBB0_19 jp .LBB0_19 .loc 1 0 13 # = /usr/src/lib/msun/src/catrig.c:0:13 fxch %st(3) fucom %st(1) fstp %st(1) fnstsw %ax sahf fldz fxch %st(1) fxch %st(3) jne .LBB0_19 jp .LBB0_19 [...] .LBB0_19: # %do.body .loc 1 0 8 is_stmt 0 # = /usr/src/lib/msun/src/catrig.c:0:8 fstp %st(1) .loc 1 318 2 is_stmt 1 # = /usr/src/lib/msun/src/catrig.c:318:2 fld1 fadds tiny fstps 168(%esp) and for amd64: .loc 1 314 8 is_stmt 1 # = /usr/src/lib/msun/src/catrig.c:314:8 pxor %xmm2, %xmm2 .loc 1 314 13 is_stmt 0 # = /usr/src/lib/msun/src/catrig.c:314:13 ucomisd %xmm2, %xmm4 jne .LBB0_15 jp .LBB0_15 .loc 1 0 13 # = /usr/src/lib/msun/src/catrig.c:0:13 ucomisd %xmm2, %xmm3 jne .LBB0_15 jnp .LBB0_21 .LBB0_15: # %do.body .loc 1 318 2 is_stmt 1 # = /usr/src/lib/msun/src/catrig.c:318:2 movss tiny(%rip), %xmm2 # xmm2 =3D mem[0],zero,zero,zero addss .LCPI0_2(%rip), %xmm2 .Ltmp11: movss %xmm2, -16(%rbp) E.g., these all look good, at least with regards to not optimizing out the desired addition. The only compiler I could find that does optimize everything away (at least in the simplified test case), is the Intel compiler: https://godbolt.org/g/g1UT2m -Dimitry --Apple-Mail=_4FBC88C3-4C7E-4D97-8BD0-773DBE95BCD3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlkXBVEACgkQsF6jCi4glqP6KQCg2xk6WB11svnu92R6Rr2NtmO5 9TIAoK00DaX+gGpjflMpSreyQ5iVCdy0 =FHkh -----END PGP SIGNATURE----- --Apple-Mail=_4FBC88C3-4C7E-4D97-8BD0-773DBE95BCD3-- From owner-freebsd-hackers@freebsd.org Sat May 13 15:24:52 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC53BD6BD87 for ; Sat, 13 May 2017 15:24:52 +0000 (UTC) (envelope-from abhinav@NetBSD.org) Received: from mollari.NetBSD.org (mollari.netbsd.org [199.233.217.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.NetBSD.org", Issuer "Postmaster NetBSD.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AE4D374A for ; Sat, 13 May 2017 15:24:52 +0000 (UTC) (envelope-from abhinav@NetBSD.org) Received: by mollari.NetBSD.org (Postfix, from userid 1507) id 1A7677A2AF; Sat, 13 May 2017 15:24:46 +0000 (UTC) To: freebsd-hackers@freebsd.org Subject: Announcing man-k.org Message-Id: <20170513152446.1A7677A2AF@mollari.NetBSD.org> Date: Sat, 13 May 2017 15:24:46 +0000 (UTC) From: abhinav@NetBSD.org (Abhinav Upadhyay) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 15:24:52 -0000 Hi, My name is Abhinav Upadhyay, I am a NetBSD user and developer. I would like to introduce http://man-k.org - a web interface to NetBSD's apropos(1). It is a full text search tool for man pages, providing support for searching FreeBSD, NetBSD, OpenBSD, Linux and Posix man pages. Apart from full text search, the man pages have syntax highlighting (at least the mdoc(7) man pages have, see [1] for example). Also, the header includes in the man pages are hyperlinked to OpenGrok for looking up the header files (see [2] for an example). I have talked about it briefly at last year's EuroBSDCon and AsiaBSDCon in the context of applying machine learning to improve ranking in NetBSD's apropos(1). But it only had support for searching NetBSD man pages back then. I would like to invite you all to use it and let me know of any feedback or suggestions you might have to improve it. :-) [1]:http://man-k.org/man/FreeBSD-12.0-CURRENT/2/kevent [2]:http://man-k.org/man/FreeBSD-12.0-CURRENT/3/strtonum - Abhinav From owner-freebsd-hackers@freebsd.org Sat May 13 16:08:23 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32364D6BB02 for ; Sat, 13 May 2017 16:08:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0EDEA1944 for ; Sat, 13 May 2017 16:08:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4DG8McC088786 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 May 2017 09:08:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4DG8MSq088785; Sat, 13 May 2017 09:08:22 -0700 (PDT) (envelope-from sgk) Date: Sat, 13 May 2017 09:08:22 -0700 From: Steve Kargl To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Subject: Re: mutex owned? Message-ID: <20170513160822.GA88653@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170513010459.GA83399@troutmask.apl.washington.edu> <20170513123836.GY1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170513123836.GY1622@kib.kiev.ua> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 16:08:23 -0000 On Sat, May 13, 2017 at 03:38:37PM +0300, Konstantin Belousov wrote: > On Fri, May 12, 2017 at 06:04:59PM -0700, Steve Kargl wrote: > > So, after 6 to 8 hours of building libreoffice, I run into this > > > > Abort trap (core dumped) > > OK (1) > > Fatal error 'mutex 0x2beaa340 own 0x189be is on list 0x69004c 0x74006e' at line 153 in file /mnt/src/lib/libthr/thread/thr_mutex.c (errno = 0) > > > > No core file identified in directory /usr/ports/editors/libreoffice/work/libreoffice-5.2.7.2/workdir/CppunitTest/dbaccess_dialog_save.test.core > > To show backtraces for crashes during test execution, > > enable core files with: > > > > ulimit -c unlimited > > > > > > Is there a known issue with libthr on i686? > > I am not aware. > > Please ensure that your libthr and libc are built with debugging symbols > (default on HEAD), obtain core dump and show me the backtrace, for the > start. I tried getting a core by restarting the build in editor/libreoffice with 'make -DNOCLEAN'. The build then completed without error. I'll restart from a clean directory and see what happens. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat May 13 16:21:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46565D6BF2E; Sat, 13 May 2017 16:21:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C32D1FCF; Sat, 13 May 2017 16:21:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4DGLrVL088880 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 May 2017 09:21:53 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4DGLrgG088879; Sat, 13 May 2017 09:21:53 -0700 (PDT) (envelope-from sgk) Date: Sat, 13 May 2017 09:21:53 -0700 From: Steve Kargl To: Dimitry Andric Cc: Bruce Evans , freebsd-hackers@freebsd.org, numerics@freebsd.org Subject: Re: catrig[fl].c and inexact Message-ID: <20170513162153.GB88653@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> <20170513060803.GA84399@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 16:21:58 -0000 On Sat, May 13, 2017 at 03:08:26PM +0200, Dimitry Andric wrote: > On 13 May 2017, at 08:08, Steve Kargl wrote: > > > > On Sat, May 13, 2017 at 11:35:49AM +1000, Bruce Evans wrote: > >> On Fri, 12 May 2017, Steve Kargl wrote: > ... > >> required for the standard magic. I planned to fix all this magic using > >> macros like raise_inexact(). > > > > If you plan to fix the magic with raise_inexact, then please > > test with a suite of compilers. AFAICT, clang is optimizing > > out the code. I haven't written a testcase to demonstrate this > > as I have other irons in the fire. > > Using the full catrig.c and -O3, I tried gcc 4.2.1, 4.7.4, 4.8.5, 4.9.4, > 5.4.0, 6.3.0 and 7.0.1, in addition to clang 3.4.1, 3.8.0, 3.9.1, 4.0.0 > and 5.0.0. Thanks for checking. I reduced catrig.c to a small self-contained program and indeed I was getting the desired addition of 1 + tiny to raise FE_INEXACT. I suppose that I'll need to add an appropriate -Wno-foo to my CFLAGS line to suppress the spurious warning, which might be tricky because -Wunused is one option I'ld like to have. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat May 13 16:55:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B18CD6B86F; Sat, 13 May 2017 16:55:38 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 004711612; Sat, 13 May 2017 16:55:37 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:470:7a58::a8c1:a7f4:edbc:3331] (unknown [IPv6:2001:470:7a58:0:a8c1:a7f4:edbc:3331]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 09D253FD9B; Sat, 13 May 2017 18:55:34 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1A165ECB-BD13-4967-A0C3-5C9609FF1B6F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: catrig[fl].c and inexact Date: Sat, 13 May 2017 18:55:27 +0200 In-Reply-To: <20170513162153.GB88653@troutmask.apl.washington.edu> Cc: freebsd-hackers@freebsd.org, numerics@freebsd.org, Bruce Evans To: sgk@troutmask.apl.washington.edu References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> <20170513060803.GA84399@troutmask.apl.washington.edu> <20170513162153.GB88653@troutmask.apl.washington.edu> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 16:55:38 -0000 --Apple-Mail=_1A165ECB-BD13-4967-A0C3-5C9609FF1B6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 May 2017, at 18:21, Steve Kargl = wrote: >=20 > On Sat, May 13, 2017 at 03:08:26PM +0200, Dimitry Andric wrote: ... >=20 >> Using the full catrig.c and -O3, I tried gcc 4.2.1, 4.7.4, 4.8.5, = 4.9.4, >> 5.4.0, 6.3.0 and 7.0.1, in addition to clang 3.4.1, 3.8.0, 3.9.1, = 4.0.0 >> and 5.0.0. >=20 > Thanks for checking. I reduced catrig.c to a small self-contained > program and indeed I was getting the desired addition of 1 + tiny > to raise FE_INEXACT. I suppose that I'll need to add an appropriate > -Wno-foo to my CFLAGS line to suppress the spurious warning, which > might be tricky because -Wunused is one option I'ld like to have. The following also gets rid of the warnings: Index: lib/msun/src/catrig.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/msun/src/catrig.c (revision 318032) +++ lib/msun/src/catrig.c (working copy) @@ -37,7 +37,7 @@ #define isinf(x) (fabs(x) =3D=3D INFINITY) #undef isnan #define isnan(x) ((x) !=3D (x)) -#define raise_inexact() do { volatile float junk =3D 1 + tiny; } = while(0) +#define raise_inexact() do { volatile float junk __unused =3D 1 = + tiny; } while(0) #undef signbit #define signbit(x) (__builtin_signbit(x)) Index: lib/msun/src/catrigf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/msun/src/catrigf.c (revision 318032) +++ lib/msun/src/catrigf.c (working copy) @@ -51,7 +51,7 @@ #define isinf(x) (fabsf(x) =3D=3D INFINITY) #undef isnan #define isnan(x) ((x) !=3D (x)) -#define raise_inexact() do { volatile float junk =3D 1 + tiny; } = while(0) +#define raise_inexact() do { volatile float junk __unused =3D 1 = + tiny; } while(0) #undef signbit #define signbit(x) (__builtin_signbitf(x)) Index: lib/msun/src/catrigl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/msun/src/catrigl.c (revision 318032) +++ lib/msun/src/catrigl.c (working copy) @@ -53,7 +53,7 @@ #define isinf(x) (fabsl(x) =3D=3D INFINITY) #undef isnan #define isnan(x) ((x) !=3D (x)) -#define raise_inexact() do { volatile float junk =3D 1 + tiny; } = while(0) +#define raise_inexact() do { volatile float junk __unused =3D 1 = + tiny; } while(0) #undef signbit #define signbit(x) (__builtin_signbitl(x)) If you are OK with that, I will commit it later today. -Dimitry --Apple-Mail=_1A165ECB-BD13-4967-A0C3-5C9609FF1B6F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlkXOoUACgkQsF6jCi4glqOjeQCgrp2JTdTaC/b3j/+gqf56C3AV GT0AoO+KGbDi+qxoOxNrez97cSEMi/Vv =zJHP -----END PGP SIGNATURE----- --Apple-Mail=_1A165ECB-BD13-4967-A0C3-5C9609FF1B6F-- From owner-freebsd-hackers@freebsd.org Sat May 13 17:12:13 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FD07D6B2A4; Sat, 13 May 2017 17:12:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B29E154; Sat, 13 May 2017 17:12:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4DHC8hu089182 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 May 2017 10:12:08 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4DHC8qr089181; Sat, 13 May 2017 10:12:08 -0700 (PDT) (envelope-from sgk) Date: Sat, 13 May 2017 10:12:08 -0700 From: Steve Kargl To: Dimitry Andric Cc: freebsd-hackers@freebsd.org, numerics@freebsd.org, Bruce Evans Subject: Re: catrig[fl].c and inexact Message-ID: <20170513171208.GA89162@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> <20170513060803.GA84399@troutmask.apl.washington.edu> <20170513162153.GB88653@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 17:12:13 -0000 On Sat, May 13, 2017 at 06:55:27PM +0200, Dimitry Andric wrote: > On 13 May 2017, at 18:21, Steve Kargl wrote: > > > > On Sat, May 13, 2017 at 03:08:26PM +0200, Dimitry Andric wrote: > ... > > > >> Using the full catrig.c and -O3, I tried gcc 4.2.1, 4.7.4, 4.8.5, 4.9.4, > >> 5.4.0, 6.3.0 and 7.0.1, in addition to clang 3.4.1, 3.8.0, 3.9.1, 4.0.0 > >> and 5.0.0. > > > > Thanks for checking. I reduced catrig.c to a small self-contained > > program and indeed I was getting the desired addition of 1 + tiny > > to raise FE_INEXACT. I suppose that I'll need to add an appropriate > > -Wno-foo to my CFLAGS line to suppress the spurious warning, which > > might be tricky because -Wunused is one option I'ld like to have. > > The following also gets rid of the warnings: > > Index: lib/msun/src/catrig.c > =================================================================== > --- lib/msun/src/catrig.c (revision 318032) > +++ lib/msun/src/catrig.c (working copy) > @@ -37,7 +37,7 @@ > #define isinf(x) (fabs(x) == INFINITY) > #undef isnan > #define isnan(x) ((x) != (x)) > -#define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) > +#define raise_inexact() do { volatile float junk __unused = 1 + tiny; } while(0) > #undef signbit > #define signbit(x) (__builtin_signbit(x)) > > Index: lib/msun/src/catrigf.c > =================================================================== > --- lib/msun/src/catrigf.c (revision 318032) > +++ lib/msun/src/catrigf.c (working copy) > @@ -51,7 +51,7 @@ > #define isinf(x) (fabsf(x) == INFINITY) > #undef isnan > #define isnan(x) ((x) != (x)) > -#define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) > +#define raise_inexact() do { volatile float junk __unused = 1 + tiny; } while(0) > #undef signbit > #define signbit(x) (__builtin_signbitf(x)) > > Index: lib/msun/src/catrigl.c > =================================================================== > --- lib/msun/src/catrigl.c (revision 318032) > +++ lib/msun/src/catrigl.c (working copy) > @@ -53,7 +53,7 @@ > #define isinf(x) (fabsl(x) == INFINITY) > #undef isnan > #define isnan(x) ((x) != (x)) > -#define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) > +#define raise_inexact() do { volatile float junk __unused = 1 + tiny; } while(0) > #undef signbit > #define signbit(x) (__builtin_signbitl(x)) > > If you are OK with that, I will commit it later today. > I'm OK with this change, but I typically defer to Bruce as he knows much more about C and floating point. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat May 13 15:58:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46766D6B85D for ; Sat, 13 May 2017 15:58:24 +0000 (UTC) (envelope-from amutu@amutu.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D08215A4 for ; Sat, 13 May 2017 15:58:24 +0000 (UTC) (envelope-from amutu@amutu.com) Received: by mail-oi0-x231.google.com with SMTP id h4so93854931oib.3 for ; Sat, 13 May 2017 08:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amutu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qs0m/UUa/uQWZZAMnSWB6nv6OJ+uWNV7LgHCFKFsBfM=; b=yDVJlZs8W7Ba0p6h4GC+xQmW5M8t3IS1vwqJYLM0RnAhWvW6Do7HBYBopu56zJ3483 FJBGxpLu4IR42sDWqzv1/RMPWAWw+TBZOK24accx1pskT+8nG+fk6RwDj2BA5QryJLft jmQXDuK3/Aw3UFGt8U2QHflvdVpi80BG4lH7RR74SzrGm/xod4/pMr0X+ZFZ4FEV563E DvNq6nBRQhYyvoQ/UenPOOEy5XBcI2Y0fa1NMNlWh+WtH+qoNPhRVE7b1zB7XtqACljv g7OIdC2LQSx3hYXZTan6V0lvQ87CGGiaC9VVFRuGo/egRrdHM8q0amotFa/w9UEdlRfl 9j3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qs0m/UUa/uQWZZAMnSWB6nv6OJ+uWNV7LgHCFKFsBfM=; b=qORGBnDmIG9bvPW2F5rBbxVXlwqMlYczIDpRLvIZogqVzCeSsBuf2cbgUX0kXGfebU REV9opv/+NtwX9ioL5i97Sb/pcGXALQkgErt7ix0ACLWxsW5X25UvL4H7cfMYlJjcBQ0 Hzn7snI91pOueS7wMb/ABdDZxDj9uIZ/mrRFyF3EhLpvRAP4Ohb//7C7ptfkcXvuM8ub sUYEjJ8pBph5x+d6YZU3aeapwFGZk8yGEuNLAoDgCW4ALYNUXdiGnT/4/Z4ddoaJrsKX 4ZHNaO4bpYHabQhrPW69sn62MbcPIv9te6gzW6vSLNnI8b0z9ZKkxu+W/iJb6pOcyVfq u+CQ== X-Gm-Message-State: AODbwcCehP6lWbX6txqNY7kuZEfh4i17GqkxQvKDwVkpkowZBseEDCMx PSK1jUMEasBcYc4j/qA= X-Received: by 10.202.193.6 with SMTP id r6mr4896592oif.129.1494691103266; Sat, 13 May 2017 08:58:23 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com. [209.85.218.52]) by smtp.gmail.com with ESMTPSA id z23sm3025870oia.26.2017.05.13.08.58.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 May 2017 08:58:22 -0700 (PDT) Received: by mail-oi0-f52.google.com with SMTP id l18so93901056oig.2 for ; Sat, 13 May 2017 08:58:22 -0700 (PDT) X-Received: by 10.202.218.135 with SMTP id r129mr4286149oig.52.1494691102693; Sat, 13 May 2017 08:58:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.134.72 with HTTP; Sat, 13 May 2017 08:58:22 -0700 (PDT) Received: by 10.74.134.72 with HTTP; Sat, 13 May 2017 08:58:22 -0700 (PDT) In-Reply-To: <20170513152446.1A7677A2AF@mollari.NetBSD.org> References: <20170513152446.1A7677A2AF@mollari.NetBSD.org> From: Jov Date: Sat, 13 May 2017 23:58:22 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Announcing man-k.org To: Abhinav Upadhyay Cc: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Sat, 13 May 2017 17:32:10 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 15:58:24 -0000 It's a useful tool,thanks! 2017=E5=B9=B45=E6=9C=8813=E6=97=A5 11:25 PM=EF=BC=8C"Abhinav Upadhyay" =E5=86=99=E9=81=93=EF=BC=9A > Hi, > > My name is Abhinav Upadhyay, I am a NetBSD user and developer. I would > like to > introduce http://man-k.org - a web interface to NetBSD's apropos(1). It > is a > full text search tool for man pages, providing support for searching > FreeBSD, > NetBSD, OpenBSD, Linux and Posix man pages. > > Apart from full text search, the man pages have syntax highlighting (at > least > the mdoc(7) man pages have, see [1] for example). Also, the header > includes in > the man pages are hyperlinked to OpenGrok for looking up the header files > (see [2] for an example). > > I have talked about it briefly at last year's EuroBSDCon and AsiaBSDCon i= n > the > context of applying machine learning to improve ranking in NetBSD's > apropos(1). > But it only had support for searching NetBSD man pages back then. > > I would like to invite you all to use it and let me know of any feedback = or > suggestions you might have to improve it. :-) > > [1]:http://man-k.org/man/FreeBSD-12.0-CURRENT/2/kevent > [2]:http://man-k.org/man/FreeBSD-12.0-CURRENT/3/strtonum > > - > Abhinav > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Sat May 13 16:05:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F338FD6BA9D; Sat, 13 May 2017 16:05:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 9E66718F7; Sat, 13 May 2017 16:05:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 44982D6B4B0; Sun, 14 May 2017 02:05:33 +1000 (AEST) Date: Sun, 14 May 2017 02:05:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: catrig[fl].c and inexact In-Reply-To: <20170513060803.GA84399@troutmask.apl.washington.edu> Message-ID: <20170514011600.D1038@besplex.bde.org> References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> <20170513060803.GA84399@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=NOglxHdSkPoQZBT6KtcA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Sat, 13 May 2017 17:47:29 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 16:05:38 -0000 On Fri, 12 May 2017, Steve Kargl wrote: > On Sat, May 13, 2017 at 11:35:49AM +1000, Bruce Evans wrote: >> On Fri, 12 May 2017, Steve Kargl wrote: >> >>> ... >>> /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:56:45: note: expanded from >>> macro 'raise_inexact' >>> #define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) >>> ^ >>> Grepping catrig.o for the variable 'junk' suggests that 'junk' is >>> optimized out (with at least -O2). It is a local variable, so should be and is allocated on the stack, so you will never find it using grep. The problem seems to be that all compilers generated the intended code, but clang warns anyway. >> Just another bug in clang. Volatile variables cannot be optimized out >> (if they are accessed). > > Does this depend on scope? 'junk' is local to the do {...} while(0); > construct. Can a compiler completely eliminate a do-nothing scoping > unit? I don't know C well enough to know. I do know what I have > observed in clang. The semantics of volatile, but as a practical matter standards shouldn't specify much and compilers should be very conservative. BTW, I recently noticed that volatile doesn't work right in bus space macros. Some reduce to *(volatile int *)var = val, where var is for memory mapped-i/o that takes 10000 times as long as normal memory to access. Compilers still unroll loops setting such variables. This is only a pessimization for space. >>> ... >>> @@ -315,7 +315,7 @@ casinh(double complex z) >>> return (z); >>> >>> /* All remaining cases are inexact. */ >>> - raise_inexact(); >>> + raise_inexact(new_y); >>> >>> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) >>> return (z); >> >> Now it doesn't take compiler bugs to optimize it out, since new_y is not >> volatile, and a good compiler would optimize it out in all cases. > > I've yet to find a good compiler. They all seem to have bugs. > >> new_y >> is obviously unused before the early returns, so it doesn't need to be >> evalated before the returns as far as the compiler can see. Later, >> new_y is initialized indirectly, and the compiler can see that too (not >> so easily, so it can see that raise_inexact() has no effect except possibly >> for its side effect of raising inexact for 1 + tiny. > > The later call passes the address of new_y to the routine. How > can the compiler short of inlining the called routine know that > the value assigned to new_y isn't used? The compiler does full inlining even when you don't want it. Full analysis of the whole source file is fundamental for generating useful warnings with -Wunused. Without full analysis, the compiler would have to assume that new_y is used uninitialized and either suppress warnings for all variables that might be initialized indirectly (including via aliased pointers), or generate many bogus warnings that variables "might be" used uninitialized. Old compilers mostly did the latter, and we still see ocasional spurious warnings from gcc-4.2.1. Old compilers also have man pages in which this is partly documented. gcc-3.3.3(1) says that: - Wuninitialized is null without -O - Wuninitialized is never generated for volatile variables - Wuninitialized is not the default since gcc is not smart enough to handle it well gcc-4.2.1(1) says much the same, plus that -Wall implies -Wuninitialized. It setill says that the compiler is not smart, and doesn't seem to document improvements that make this warning reasonable as the default with -Wall. This is mostly because -O now implies -funit-at-a-time, which I usually don't want, but which gives the full analysis needed for -Wunitialized and -Wunused. I usually don't want this because: - it slows down compilation - it allows unwanted inlining - it allows unportable code. clang doesn't support -funit-at-a-time. >> The change might defeat the intent of the original code in another way. >> 'junk' is intentionally independent of other variables, so that there are >> no dependencies on it. If the compiler doesn't optimize away the assignment >> to new_y, then it is probably because it doesn't see that the assignment is >> dead, so there is a dependency. > > It may defeat the intent of the original code, but it seems that > the original code provokes undefined behavior. Defined, but perhaps not what is wanted. It is using -W flags that gives undefined behaviour. They are undefined by the C standard, and also undefined by compilers with stub man pages. >> Actually, we want the variable 'junk' to be optimized away. We only want >> the side effect of evaluating 1 + tiny. Compilers have bugs evaluating >> expressions like 1 + tiny, tiny*tiny and huge*huge, and we use assignments >> of the result to volatile variables in tens if not hundreds of places to >> try to work around compiler bugs. If that doesn't work here, then all the >> other places are probably broken too. The other places mostly use a static >> volatile, while this uses an auto volatile. 'tiny' is also volatile, as >> required for the standard magic. I planned to fix all this magic using >> macros like raise_inexact(). > > If you plan to fix the magic with raise_inexact, then please > test with a suite of compilers. AFAICT, clang is optimizing > out the code. I haven't written a testcase to demonstrate this > as I have other irons in the fire. I only tested with 4 compilers when I wrote it. Actually, we agreed not to worry about compiler bugs for setting fenv, especially for compilers with even more of them than gcc. libm only has the volatile hack needed to fix huge*huge for clang in some places (gcc evaluates huge*huge at run time but tiny*tiny at compile time, so libm has more volatile hacks for the latter). Not to mention hacks to remove extra precision for huge*huge and tiny*tiny. On i386 with i387, huge*huge doesn't overflow since it is evaluated in extra precision. The wrong result is returned and the wrong result is used if it is assigned to a variable that can hold the extra precision. Overflow only occurs if the variable is converted to float ot double, and STRICT_ASSIGN() or a volatile hack must be used for this to work around other compiler bugs (which are actually features, but not allowed by C standards). C11 and compiler non-support for C11 breaks this further. C11 adds the extra pessimization auns subtraction of value of requiring extra precision (and range) to be destroyed on function return. clang ignores this requirement. Newer gcc supports it under certain pessimal CFLAGS including -std=c11. Bruce. From owner-freebsd-hackers@freebsd.org Sat May 13 16:19:34 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 232CFD6BDC3; Sat, 13 May 2017 16:19:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id DF7351D9F; Sat, 13 May 2017 16:19:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id B18B842C3B3; Sun, 14 May 2017 02:19:24 +1000 (AEST) Date: Sun, 14 May 2017 02:19:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Dimitry Andric cc: sgk@troutmask.apl.washington.edu, freebsd-hackers@freebsd.org, numerics@freebsd.org Subject: Re: catrig[fl].c and inexact In-Reply-To: Message-ID: <20170514020559.F1038@besplex.bde.org> References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> <20170513060803.GA84399@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=PeOOapuUAAAA:8 a=Wnqw8I5xCDkGpBuh6r0A:9 a=CjuIK1q_8ugA:10 a=0BaqRfgCL6CLbWgV2pdm:22 X-Mailman-Approved-At: Sat, 13 May 2017 18:04:22 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 16:19:34 -0000 On Sat, 13 May 2017, Dimitry Andric wrote: > On 13 May 2017, at 08:08, Steve Kargl wrote: >> >> On Sat, May 13, 2017 at 11:35:49AM +1000, Bruce Evans wrote: >>> On Fri, 12 May 2017, Steve Kargl wrote: > ... >>> required for the standard magic. I planned to fix all this magic using >>> macros like raise_inexact(). >> >> If you plan to fix the magic with raise_inexact, then please >> test with a suite of compilers. AFAICT, clang is optimizing >> out the code. I haven't written a testcase to demonstrate this >> as I have other irons in the fire. > > Using the full catrig.c and -O3, I tried gcc 4.2.1, 4.7.4, 4.8.5, 4.9.4, > 5.4.0, 6.3.0 and 7.0.1, in addition to clang 3.4.1, 3.8.0, 3.9.1, 4.0.0 > and 5.0.0. All versions of gcc produced something similar to the > following for i386: Yes, all compilers I tried (only gcc-3.3.3, gcc-4.2.1 and clang-3.9.0) generate the intended code, but clang-3.9.0 also generates a -Wunused warning about the variable that it has just used to generated the intended code! > # /usr/src/lib/msun/src/catrig.c:318: raise_inexact(); > flds tiny # tiny > fadds .LC2 # > fstps 120(%esp) # junk I don't know how to ask for the best code, which is more like flds tiny fadds one ffree %st(0) # or fstp %st(0) -- MD optimization but the best code runs insignificantly faster in practice. > and for amd64: > [...] > .L34: > .LBB33: > # /usr/src/lib/msun/src/catrig.c:318: raise_inexact(); > movss tiny(%rip), %xmm0 # tiny, tiny.0_28 > addss .LC13(%rip), %xmm0 #, _29 > movss %xmm0, 188(%rsp) # _29, junk Discarding the result is easier for amd64 (just omit the store). The volatile hack forces the store. > E.g., these all look good, at least with regards to not optimizing out > the desired addition. > > The only compiler I could find that does optimize everything away (at > least in the simplified test case), is the Intel compiler: > > https://godbolt.org/g/g1UT2m Urk. Bruce From owner-freebsd-hackers@freebsd.org Sat May 13 18:21:41 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26A47D6B00F; Sat, 13 May 2017 18:21:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id 9B43EEE1; Sat, 13 May 2017 18:21:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id D78651A400E; Sun, 14 May 2017 04:21:31 +1000 (AEST) Date: Sun, 14 May 2017 04:21:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Mark Millard cc: sgk@troutmask.apl.washington.edu, Bruce Evans , freebsd-hackers@freebsd.org, numerics@freebsd.org Subject: Re: catrig[fl].c and inexact In-Reply-To: Message-ID: <20170514023721.O1230@besplex.bde.org> References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> <20170513060803.GA84399@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=iROBt-5bZgHvOzUyjZ0A:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Sat, 13 May 2017 19:16:32 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 18:21:41 -0000 On Sat, 13 May 2017, Mark Millard wrote: > > On 2017-May-12, at 11:08 PM, Steve Kargl wrote: > >> On Sat, May 13, 2017 at 11:35:49AM +1000, Bruce Evans wrote: >>> On Fri, 12 May 2017, Steve Kargl wrote: >>>> ... >>>> /usr/home/kargl/trunk/math/libm/msun/src/catrigl.c:56:45: note: expanded from >>>> macro 'raise_inexact' >>>> #define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) >>>> ^ >>>> Grepping catrig.o for the variable 'junk' suggests that 'junk' is >>>> optimized out (with at least -O2). It is easy to write unportable code that works perfectly. On i386(i387): #define use(x) __asm("" : : "t" (x)) #define raise_inexact() use(1 + tiny) looks cleaner except for the asm, and generates perfect code with fstp %st(0) and no store of the result to memory. Unfortunately, the "t" (top of i387 stack) is too unportable. "g" might be portable enough, but generatates wose code that the volatile variable. >>> Just another bug in clang. Volatile variables cannot be optimized out >>> (if they are accessed). >> >> Does this depend on scope? 'junk' is local to the do {...} while(0); >> construct. Can a compiler completely eliminate a do-nothing scoping >> unit? I don't know C well enough to know. I do know what I have >> observed in clang. > > [This note ignores other standards than C99/C11 > that might place other constraints. And I've done > no checking of compiler results, I've just looked > at a couple of the C standards.] > > Note: I've not looking to tiny's declaration. It > may contribute in a way not covered below. > > Unfortunately the declarator in an init-declarator > that has an initializer is not part of an > expression. The rules for volatile are tied to uses > in expressions, not to the declarator. (Which is a > hole in the language definition as far as I can > tell.) But the very first mention of volatile in C99 (5.1.2.3 Program Execution #1) says that "Accessing a volatile object ... [is a side effect]. ... [All previous side effects shall be complete at certain sequence points.]" It doesn't make any exceptions for auto objects. Also, #3 explicitly says for side effects in expressions that the implementation may optimize away the evaluation if it can determine that the evaluation has no side effects, including by calling a function or accessing a volatile object. But here the compiler can't do that for 1 + tiny, since this expression does have side effects (perhaps modulo pragma FENV_ACCESS). This rule is redundant if not wrong. The implementation can always use the "as if" rule to avoid doing work to produce nothing. And according to #1, any access to a volatile variable has side effects, so the compiler can never determine that an evaluation involving volatile variables has no side effects. So the correctness of the compiler using #3 to avoid the assignment reduces to the standard breaking its own definition of volatile, and then the compiler using the broken definition. > There is one part of the wording that might mitigate > this, tied to a full declarator having a sequence > point at its end despite the declarator itself not > being an expression, even if its initializer is > one. There is another wording detail that might > as well. Surely the assignment gives a sequence point for initializers? Actually, this is not too clear. I don't even like initialization in declarations, partly because it obscure the order, and only wrote the code with an initializer to get a 1-line macro. It could be written as "volatile float junk; junk = 1 + tiny;". Also, the use() macro can be written in C, with similar problems to the asm version, as "#define use(x) do { volatile float junk; junk = x; } while (0)" or better in gnuC as "#define use(x) do { volatile __typeof(x) junk; junk = x; } while (0)". This allows keeping the volatile hack and variations to make it work (maybe just __unused) in 1 place. #9 (Example 1) says that an implementation may make the volatile keyword redundant, essentially by making volatile-memory non-magic. I don't like this. It reduces the side effects of volatile to just the ordering of accesses to volatiles relative to sequence points, but practical implementations need much more than that. This clause just says that impractical implementations are allowed, but so does the "as if" rule. #10 is much more of the same. 6.7.3 #6 says that accesses to a volatile-qualified object "may" have side effects unknown to the implementation. Misimplementations may still apply the "as if" rule and comform to this clause weaselishly by knowing their own badness. They just have to do what is allowed in Example 1 to make volatile have no useful effect. Then this clause is null. > Still, overall it would seem safer to be sure there > is an expression that references the volatile object, > not having only its declarator. But I would not take > even that as a guarantee under the C standards. The standard seems a bit too weighted towards read accesses. We cold try writing to a non-volatile variable and reading back the result as volatile using a *(volatile type_t *)&var hack. But that would give an unwanted extra memory access. > It may seem a silly difference but: > > do { volatile float junk=1; junk+=tiny; } while(0) > > may well be a better way of writing the "must > evaluate" part of the intent simply because > junk is used in an expression. Also it has both read > and write access, so is a little more "used". The > sequence point before the assignment can help avoid > compile-time evaluation as well. That would give 1 more unwanted memory access (if it works normally): - write 1 to junk - read 1 from junk; add tiny (usually) in a register - write result to junk. > Details if you care. . . > > I used the C99 and C11 definitions here, I > reference C11 section numbering but C99 agrees > as I remember. > > 5.1.2.3 Program execution says: > > "Accessing a volatile object, modifying an object, > modifying a file, or calling a function that does > any of those operations are all side effects, > which are changes in the state of the execution > environment. Evaluation of an expression may > produce side effects." > > Note that raising inexact does not fit in the > definition of side effect as far as I can tell. > So a compiler need not consider such a thing > for side-effect issues if I understand right. I think it does, modulo #pragma FENV_ACCESS. Indeed, F.7.1 says it does explicitly (and without Annex F, floating point can do almost anything). It says that when FENV_ACCESS is "on" (should be "ON"), for FP operations that implicitly raise exception flags, these changes to the FP state are treated as side effects which respect sequence points [footnote 291]. The footnote wastes space to remind the reader that optimizations are allowed when FENV_ACCESS is "off". > [C11 specific wording:] "The presence of a > sequence point between the evaluations of > expressions A and B implies that every value > computation and side effect associated with A > is sequenced before every value compuation and > side effect associated with B." > > [C99 is similar but is before the detailed > "sequenced before" definition.] > > "An actual implementation need not evaluate part > of an expression if it can deduce that its value > is not used and that no needed side effects are > produced (including any caused by calling a > function or accessing a volatile object)." I didn't expect any problems with volatile or sequence points. With FENV_ACCESS OFF, the compiler is free to ignore the side effect for 1+tiny, but with FENV_ACCESS broken in all available compilers, we have to assume that the compiler doesn't ignore this side affect. In practice, compilers do ignore it for (void)(1+tiny) with tiny non-volatile, so we use a several volatile hacks. Volatile for tiny alone isn't enough... > Can a accessing a volatile object ever be > classified as having "no needed side effects"? > More on this later. [Remember what "side effect" > excludes, as noted earlier. So some consequences > need not be considered by the compiler, all in > the name of optimizations.] ...we need the write access to junk it to have side effects. Since tiny is volatile, 1+tiny has an unknown value even with FENV_ACCESS OFF. Then we want the side effects for accessing junk to depend on the value, so that the value must be calculated even though it it unused except for its effects on the side effects. This is fragile. > 6.7.3 Type Qualifiers says: > > "An object that has volatile-qualified type . . . > Therefore any expression referring to such as object > shall be evaluated strictly according to the rules > of the abstract machine, as described in 5.1.2.3. > Furthermore, at every sequence point the value last > stored in the object shall agree with that prescribed > by the abstract machine, except as modified by the > unknown factors mentioned previously. What constitutes > an access to an object that has volatile-qualified > type is implementation-defined." > > This part is mixed: what the sequence point wording > giveth the last sentence taketh away. (More later.) The implementation must work for memory mapped-devices since that is the most important case for us. Anything that reads or writes a value to a memory-mapped device has lots of side effects that depend on the value. So junk = 1 + tiny must load tiny if tiny is for a memory-mapped device, evaluate 1+tiny to get a value to store, and do the store if junk is for a memory-mapped device. The compiler is doing too much optimization if it "knows" that junk is not for a memory-mapped device because the compiler allocated it on the stack. The compiler allocated the static tiny in ordinary memory too. If volatile is broken for tiny, and FENV_ACCESS is OFF or broken (unsupported) then the compiler is free to evaluate 1+tiny as 1 at compile time, and similarly for later expressions involving the result. extern volatile usually prevents the compiler from knowing that the variable is not for device memory. > It also says in a note (134): > > "A volatile declaration may be used to describe an > object corresponding to a memory-mapped input/output > port or an object accessed by an asynchronously > interrupting function. Actions on objects so declared > shall, not be "optimized out" by an implementation > or reordered except as permitted by the rules for > evaluating expressions." "so declared" must be read as simple "volatile", since there is no declaration like "volatile memory mapped ..." though such declarations would be very useful for kernels. > Since rules for evaluating expressions are not rules > for declarators (vs. initializers), this could be > read as not allowing the "optimize out". (But the > abstract machine's description is not explicit about > declarators for such issues.) It just allows all optimizations which the compiler can tell are safe. But compilers can never tell. Maybe the programmer mapped the stack memory-mapped... This is well outside the scope of the C abstract machine, but would be just another hack for kernels. > The C99 Rationale: > > The C99 Rationale was explicit about static > volatile for a memory mapped I/O register, > static const volatile for a memory mapped > input port, const volatile and volatile > for variables shared across processes. To > some extent this identifies examples of > contexts with "needed side effects" that > have hardware details to take into account. > > For taking into account hardware details: > ". . . Whatever decision are adopted on such > issues must be documented, as volatile access > is implementation-defined". > > For volatile use with no explicitly identified > hardware details: volatile would appear to be > no more than a potential hint for such a > context, not an effective requirement. The > implementation-defined status could allow lack > of access. > > Overall, based on what I see in the C99 and > C11 language definitions, I'd not be willing to > declare clang wrong (if it did optimize out junk), > even with my alternative formulation. > > C does not have an explicit Principle of Least > Astonishment as a official guideline to its > interpretation and the rules are very biased to > allowing so-called optimizations. "junk" does not > fit with being shared across processes (for > example its address is not handed to anything) > and is not static or even global. There is no > known type of potential context for specific > hardware details that would need to be taken > into account for junk. That in turn leaves open > not accessing it at all as far as I can tell. Yes, it is only a hint, and the C standard would be improved by saying just that, or requiring the strong meaning that is needed in practice. The strong meaning is that accesses to volatile variables always have side effects even if the implementation "knows" that the don't. Bruce From owner-freebsd-hackers@freebsd.org Sat May 13 19:14:57 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52341D6BFF3; Sat, 13 May 2017 19:14:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 10ACDA9B; Sat, 13 May 2017 19:14:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 6F0963C6D9F; Sun, 14 May 2017 05:14:54 +1000 (AEST) Date: Sun, 14 May 2017 05:14:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Dimitry Andric cc: sgk@troutmask.apl.washington.edu, freebsd-hackers@freebsd.org, numerics@freebsd.org Subject: Re: catrig[fl].c and inexact In-Reply-To: Message-ID: <20170514043645.G2059@besplex.bde.org> References: <20170512215654.GA82545@troutmask.apl.washington.edu> <20170513103208.M845@besplex.bde.org> <20170513060803.GA84399@troutmask.apl.washington.edu> <20170513162153.GB88653@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=Y88NXTGeRKpz0WgPRmcA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Sat, 13 May 2017 19:35:05 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 19:14:57 -0000 On Sat, 13 May 2017, Dimitry Andric wrote: > On 13 May 2017, at 18:21, Steve Kargl wrote: >> >> On Sat, May 13, 2017 at 03:08:26PM +0200, Dimitry Andric wrote: > ... >> >>> Using the full catrig.c and -O3, I tried gcc 4.2.1, 4.7.4, 4.8.5, 4.9.4, >>> 5.4.0, 6.3.0 and 7.0.1, in addition to clang 3.4.1, 3.8.0, 3.9.1, 4.0.0 >>> and 5.0.0. >> >> Thanks for checking. I reduced catrig.c to a small self-contained >> program and indeed I was getting the desired addition of 1 + tiny >> to raise FE_INEXACT. I suppose that I'll need to add an appropriate >> -Wno-foo to my CFLAGS line to suppress the spurious warning, which >> might be tricky because -Wunused is one option I'ld like to have. > > The following also gets rid of the warnings: > > Index: lib/msun/src/catrig.c > =================================================================== > --- lib/msun/src/catrig.c (revision 318032) > +++ lib/msun/src/catrig.c (working copy) > @@ -37,7 +37,7 @@ > #define isinf(x) (fabs(x) == INFINITY) > #undef isnan > #define isnan(x) ((x) != (x)) > -#define raise_inexact() do { volatile float junk = 1 + tiny; } while(0) > +#define raise_inexact() do { volatile float junk __unused = 1 + tiny; } while(0) > #undef signbit > #define signbit(x) (__builtin_signbit(x)) > ... > > If you are OK with that, I will commit it later today. It is what I said was best yeseterday :-). Except, __unused is an obfuscation meaning __used. I couldn't get __used to work today either. It works with static variables, but for auto variables it generates "'__used__' attribute ignored" for both clang-3.9.0 and gcc-4.2.1, even without any -W flags to ask for excessive warnings. Today I looked at the macro used(expr), which would be used like used(1 + tiny) for inexact, used(huge * huge) for overflow, and used(tiny * tiny) for underflow. The difficulty is to declare the variable to hold the result, especially since we don't want this variable to be in memory. Also in some cases, we would like to return the result. For overflow, we can do either: ({ volatile float junk __unused = huge * huge; INFINITY; }) or ({ __typeof(huge) r; STRICT_ASSIGN(..., huge * huge); r; }) with different tradoffs (the second is broken if r is not used and there is no volatile hidden in STRICT_ASSIGN()), or better, only load huge once (float t = huge; junk = t * t;). Bruce From owner-freebsd-hackers@freebsd.org Sat May 13 20:55:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78514D6B1DC; Sat, 13 May 2017 20:55:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 535621C2C; Sat, 13 May 2017 20:55:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v4DKtHpT091964 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 May 2017 13:55:18 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v4DKtH98091963; Sat, 13 May 2017 13:55:17 -0700 (PDT) (envelope-from sgk) Date: Sat, 13 May 2017 13:55:17 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170513205517.GA91911@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> <20170429005924.GA37947@troutmask.apl.washington.edu> <20170429151457.F809@besplex.bde.org> <20170429194239.P3294@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170429194239.P3294@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 20:55:19 -0000 On Sat, Apr 29, 2017 at 08:19:23PM +1000, Bruce Evans wrote: > On Sat, 29 Apr 2017, Bruce Evans wrote: > > On Fri, 28 Apr 2017, Steve Kargl wrote: > >> On Fri, Apr 28, 2017 at 04:35:52PM -0700, Steve Kargl wrote: > >>> > >>> I was just backtracking with __kernel_sinpi. This gets a max ULP < 0.61. > > > > Comments on this below. > > > > This is all rather over-engineered. Optimizing these functions is > > unimportant comparing with finishing cosl() and sinl() and optimizing > > all of the standard trig functions better, but we need correctness. > > But I now see many simplifications and improvements: > > > > (1) There is no need for new kernels. The standard kernels already handle > > extra precision using approximations like: > > > > sin(x+y) ~= sin(x) + (1-x*x/2)*y. > > > > Simply reduce x and write Pi*x = hi+lo. Then > > > > sin(Pi*x) = __kernel_sin(hi, lo, 1). > > > > I now see how to do the extra-precision calculations without any > > multiplications. > > But that is over-engineered too. > > Using the standard kernels is easy and works well: Maybe works well. See below. > Efficiency is very good in some cases, but anomalous in others: all > times in cycles, on i386, on the range [0, 0.25] > > athlon-xp, gcc-3.3 Haswell, gcc-3.3 Haswell, gcc-4.2.1 > cos: 61-62 44 43 > cospi: 69-71 (8-9 extra) 78 (anomalous...) 42 (faster to do more!) > sin: 59-60 51 37 > sinpi: 67-68 (8 extra) 80 42 > tan: 136-172 93-195 67-94 > tanpi: 144-187 (8-15 extra) 145-176 61-189 > > That was a throughput test. Latency is not so good. My latency test > doesn't use serializing instructions, but uses random args and the > partial serialization of making each result depend on the previous > one. > > athlon-xp, gcc-3.3 Haswell, gcc-3.3 Haswell, gcc-4.2.1 > cos: 84-85 69 79 > cospi: 103-104 (19-21 extra) 117 94 > sin: 75-76 89 77 > sinpi: 105-106 (30 extra) 116 90 > tan: 168-170 167-168 147 > tanpi: 191-194 (23-24 extra) 191 154 > > This also indicates that the longest times for tan in the throughput > test are what happens when the function doesn't run in parallel with > itself. The high-degree polynomial and other complications in tan() > are too complicated for much cross-function parallelism. > > Anywyay, it looks like the cost of using the kernel is at most 8-9 > in the parallel case and at most 30 in the serial case. The extra- > precision code has about 10 dependent instructions, so it s is > doing OK to take 30. Based on other replies in this email exchange, I have gone back and looked at improvements to my __kernel_{cos|sin|tan}pi[fl] routines. The improvements where for both accuracy and speed. I have tested on i686 and x86_64 systems with libm built with -O2 -march=native -mtune=native. My timing loop is of the form float dx, f, x; long i, k; f = 0; k = 1 << 23; dx = (xmax - xmin) / (k - 1); time_start(); for (i = 0; i < k; i++) { x = xmin + i * dx; f += cospif(x); }; time_end(); x = (time_cpu() / k) * 1.e6; printf("cospif time: %.4f usec per call\n", x); if (f == 0) printf("Can't happen!\n"); The assumption here is that loop overhead is the same for all tested kernels. Test intervals for kernels. float: [0x1p-14, 0.25] double: [0x1p-29, 0.25] ld80: [0x1p-34, 0.25] Core2 Duo T7250 @ 2.00GHz || AMD FX8350 Eight-Core CPU (1995.05-MHz 686-class) || (4018.34-MHz K8-class) ----------------------------------++-------------------------- | Horner | Estrin | Fdlibm || Horner | Estrin | Fdlibm -------+--------+--------+--------++--------+--------+-------- cospif | 0.0223 | | 0.0325 || 0.0112 | | 0.0085 sinpif | 0.0233 | Note 1 | 0.0309 || 0.0125 | | 0.0085 tanpif | 0.0340 | | Note 2 || 0.0222 | | -------+--------+--------+--------++--------+--------+-------- cospi | 0.0641 | 0.0571 | 0.0604 || 0.0157 | 0.0142 | 0.0149 sinpi | 0.0722 | 0.0626 | 0.0712 || 0.0178 | 0.0161 | 0.0166 tanpi | 0.1049 | 0.0801 | || 0.0323 | 0.0238 | -------+--------+--------+--------++--------+--------+-------- cospil | 0.0817 | 0.0716 | 0.0921 || 0.0558 | 0.0560 | 0.0755 sinpil | 0.0951 | 0.0847 | 0.0994 || 0.0627 | 0.0568 | 0.0768 tanpil | 0.1310 | 0.1004 | || 0.1005 | 0.0827 | -------+--------+--------+--------++--------+--------+-------- Time in usec/call. Note 1. In re-arranging the polynomials for Estrin's method and float, I found appreciable benefit. Note 2. I have been unable to use the tan[fl] kernels to implement satisfactory kernels for tanpi[fl]. In particular, for x in [0.25,0.5] and using tanf kernel leads to 6 digit ULPs in 0.5 whereas my kernel near 2 ULP. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow