Date: Mon, 14 Mar 2016 13:30:23 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Dimitry Andric <dim@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: clang gets numerical underflow wrong, please fix. Message-ID: <20160314203023.GA34638@troutmask.apl.washington.edu> In-Reply-To: <65DA5D5E-6BEE-4522-9478-B659724F9CDC@FreeBSD.org> References: <20160313182521.GA25361@troutmask.apl.washington.edu> <74970883-FE44-47C0-BDA0-92DB0723398A@FreeBSD.org> <20160313201004.GA26343@troutmask.apl.washington.edu> <A70D119A-514A-4949-9BCB-CA344650BDB5@FreeBSD.org> <20160314015311.GA28237@troutmask.apl.washington.edu> <65DA5D5E-6BEE-4522-9478-B659724F9CDC@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 14, 2016 at 08:23:33PM +0100, Dimitry Andric wrote: > > Maybe this is a usable workaround for libm. > Thanks for looking into this. I just read the audit trail at llvm.org. Searching the clang user manual turns up The support for standard C in clang is feature-complete except for the C99 floating-point pragmas. There is no other statement concerning the implementation defined behavior. The understated assumption that FENV_ACCESS is tacitly set to OFF should be documented. It won't help possible libm issues. The libm function is trying to raise the FE_UNDERFLOW signal and return 0 to a program. As it is now, the libm function returns a nonzero invalid result. -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160314203023.GA34638>