From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5412 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: implicit conversion loses floating-point precision Date: Sat, 5 Jul 2014 08:43:58 -0400 Message-ID: <20140705124358.GJ179@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1404564262 1950 80.91.229.3 (5 Jul 2014 12:44:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jul 2014 12:44:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5417-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 05 14:44:13 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1X3PK8-00071z-3F for gllmg-musl@plane.gmane.org; Sat, 05 Jul 2014 14:44:12 +0200 Original-Received: (qmail 9904 invoked by uid 550); 5 Jul 2014 12:44:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9896 invoked from network); 5 Jul 2014 12:44:10 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5412 Archived-At: On Sat, Jul 05, 2014 at 02:25:02PM +0300, Vasyl Vavrychuk wrote: > Hi, > > For musl 1.1.3 building with libc++ and clang I get > > /usr/local/opt/musl/include/math.h:97:1: error: implicit conversion loses > floating-point precision: 'double_t' (aka 'double') to 'float' > [-Werror,-Wconversion] This warning is bogus. If the compiler were behaving correctly, x=y+z, where x, y, and z all have type float or all have type double, would have to produce this warning on archs (like i386) with FLT_EVAL_METHOD==2, but I doubt it does. Unfortunately, it doesn't seem to be able to separate this bogus behavior from the other aspects of -Wconversion, which, while I don't agree with, I understand that many projects may be using this option. > __ISREL_DEF(less, <, double_t) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/local/opt/musl/include/math.h:94:23: note: expanded from macro > '__ISREL_DEF' > { return !isunordered(__x,__y) && __x op __y; } > ~~~~~~~~~~~~^~~~~~~~ > /usr/local/opt/musl/include/math.h:90:34: note: expanded from macro > 'isunordered' > #define isunordered(x,y) (isnan((x)) ? ((void)(y),1) : isnan((y))) > ^ > /usr/local/opt/musl/include/math.h:67:45: note: expanded from macro 'isnan' > sizeof(x) == sizeof(float) ? (__FLOAT_BITS(x) & 0x7fffffff) > > 0x7f800000 : \ This seems to be the problem: it's issuing warnings for the conversion to float in the branch that only happens if x already has type float. So this seems to be a bug in clang. I don't see any way around it without turning off the warning on clang's side. From musl's side, working around it seems to require non-portable, compiler-specific logic in the public headers which is not something we want, especially when the issue it's addressing is only a warning being issued due to compiler bugs. If you see a way to work around it without doing this, let me know. Also, normally compilers suppress any warnings from system headers or code expanded from system headers, so perhaps clang isn't identifying musl's headers as being system headers. If you're trying to use a clang that wasn't built to target musl, by suppressing the default header and library directories, this might be the cause; you need to use -isystem rather than -I in that case. Hope this helps! Rich