From owner-freebsd-current@FreeBSD.ORG Sun Aug 25 15:57:31 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 54D4D4F3; Sun, 25 Aug 2013 15:57:31 +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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3504D24B2; Sun, 25 Aug 2013 15:57:31 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r7PFvUdn060144; Sun, 25 Aug 2013 08:57:30 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r7PFvUdZ060143; Sun, 25 Aug 2013 08:57:30 -0700 (PDT) (envelope-from sgk) Date: Sun, 25 Aug 2013 08:57:30 -0700 From: Steve Kargl To: David Chisnall Subject: Re: GCC withdraw Message-ID: <20130825155730.GA59962@troutmask.apl.washington.edu> References: <20130823111647.GT2951@home.opsec.eu> <521745F2.8050607@passap.ru> <20130824115158.GA88999@zxy.spb.ru> <20130824154217.GE3796@zxy.spb.ru> <20130824224204.GH3796@zxy.spb.ru> <20130824230615.GA55855@troutmask.apl.washington.edu> <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C36387A-B744-4E05-892E-AE2581D7E1ED@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Sam Fourman Jr." , toolchain@freebsd.org, Boris Samorodov , FreeBSD Current , Slawa Olhovchenkov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 15:57:31 -0000 On Sun, Aug 25, 2013 at 11:08:57AM +0100, David Chisnall wrote: > On 25 Aug 2013, at 00:06, Steve Kargl wrote: > > > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: > >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote: > >> > >>> And i found PR about clang and mplayer: ports/176272 > >>> This PR contains log with build error log. > >> > >> Please file clang bugs at http://llvm.org/bugs/ > >> > > > > As if this is going to help. > > > > http://llvm.org/bugs/show_bug.cgi?id=8532 > > > > 2 years, 9 month and counting. > > This bug relates to a corner case in complex floating point support, > which GCC in base doesn't get right either, GCC addressed issue in 4.5.0. I don't necessarily agree with the fix, but gcc did not ignore it. I understand why FreeBSD has not updated to a newer gcc base. > and which affects a tiny proportion of users yep, anyone using complex arithmetic. > and which comes with a hypothetical test case Of course, it is a trivial testcase. It was meant to be trivial to demonstrate the bug and aid the compiler writer in fixing it. > but no evidence that any real-world code is affected by it. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599 > If you have some real-world code that is compiled correctly > by GCC but incorrectly by clang as a result of this, then > please update the bug. Go read FreeBSD libm's code where I (and now others) had/have to jump through hoops with cpack[f|l] functions to avoid the problem. > Oh, and it's worth noting that clang, as an extension, supports > using initialiser lists to create complex values and so this > particular case is trivial to avoid if you use this feature, > which you will if you create complex numbers using the macro that > the C specification introduced specifically to avoid this case. See msun/src/math_private.h. But, the above is irrelevant. You missed my point, so to be blunt. Reporting the bug to llvm does not mean that it will be fixed. More importantly the problem with mplayer and clang should be reported/recorded in FreeBSD's bug database where others can find the issue when clang fails to build mplayer. The mplayer maintainer can either fix the problem or escaluate the issue upstream. -- Steve