From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2499 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: spandsp build, lrint/sqrt/pow issue Date: Tue, 18 Dec 2012 12:45:09 +0100 Message-ID: <20121218114508.GV23126@port70.net> References: <50CAF645.9000804@ojab.ru> <20121214124026.GO23126@port70.net> <50CB22CD.1070208@ojab.ru> <20121214133342.GQ23126@port70.net> <50CB35FE.2050705@ojab.ru> <50CB8250.7090804@ojab.ru> <20121215004706.GR23126@port70.net> <50CDA26C.4010908@ojab.ru> <20121216141203.GS23126@port70.net> <50D0080D.6020005@ojab.ru> 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 1355831125 25623 80.91.229.3 (18 Dec 2012 11:45:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Dec 2012 11:45:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2500-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 18 12:45:40 2012 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 1Tkvc7-0004MZ-SJ for gllmg-musl@plane.gmane.org; Tue, 18 Dec 2012 12:45:35 +0100 Original-Received: (qmail 19888 invoked by uid 550); 18 Dec 2012 11:45:21 -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 19880 invoked from network); 18 Dec 2012 11:45:21 -0000 Content-Disposition: inline In-Reply-To: <50D0080D.6020005@ojab.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2499 Archived-At: * ojab [2012-12-18 10:07:09 +0400]: > LLVM guys has closed http://llvm.org/bugs/show_bug.cgi?id=14618 as invalid. > Type expression, that mentioned above, compiles without errors on > both gcc and clang, so looks like an error anywhere else. Testcase > was: > int main() { > __typeof__(0 ? (int*)0 : (void*)1) x; > } they should not close the bug if they don't understand it.. the bug has nothing to do with integer constant expressions the more i look at it the more convinced i am that this is a big fat clang bug but you should cut down the test case to a smaller one, i cannot do that without clang, the (void*)1 was just my best guess i assume the fp and float checks work in clang so a smaller test case could be: // should be the same as __typeof__(*(double*)0) x; __typeof__(*( 0 ? (__typeof__(0 ? (double *)0 : (void *)0))0 : 0 ? (__typeof__(0 ? (double _Complex *)0 : (void *)1))0 : (__typeof__(0 ? (__typeof__(1) *)0 : (void *)1))0 )) x; if this fails like the original one then you can cut down even more by checking the individual branches: // double* x __typeof__(0 ? (double *)0 : (void *)1) x; // double _Complex* y __typeof__(0 ? (double _Complex *)0 : (void *)1) y; // void* z __typeof__(0 ? (__typeof__(1) *)0 : (void *)1) z; etc. if the above works then the error is in the __IS_FP or FLT or FLTCX macros