From owner-freebsd-numerics@FreeBSD.ORG Sun May 19 16:10:45 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 47FB1750 for ; Sun, 19 May 2013 16:10:45 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 207A1F0F for ; Sun, 19 May 2013 16:10:41 +0000 (UTC) Received: from [192.168.0.16] (CPE7cb21b17bdec-CM7cb21b17bde9.cpe.net.cable.rogers.com [99.241.130.69]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r4JGAZUE093669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 19 May 2013 16:10:35 GMT (envelope-from theraven@FreeBSD.org) From: David Chisnall Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: C99 Long Double Math Functions Message-Id: Date: Sun, 19 May 2013 12:10:28 -0400 To: "freebsd-numerics@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 16:10:45 -0000 Hi Everyone, In February, lots of people had code ready to commit for the C99 long = double math.h functions. This code is still not in and is an = increasingly serious problem for a lot of software. Two weeks from = today, I will commit a patch that just calls the double versions of = these for all of the long double functions. If you have a better = implementation of any of them, please commit it before then. Style nits = can be worked out later. Small bugs in corner cases can also be fixed = later: it is far worse for us to have no implementation of these than to = have a slightly buggy one, because it just drives people to use = platforms that have very buggy versions of them instead of FreeBSD. David With his Core hat on= From owner-freebsd-numerics@FreeBSD.ORG Sun May 19 17:38:32 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 69E02666; Sun, 19 May 2013 17:38:32 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 4F91D1C2; Sun, 19 May 2013 17:38:32 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r4JH9136096661; Sun, 19 May 2013 10:09:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r4JH91Sn096660; Sun, 19 May 2013 10:09:01 -0700 (PDT) (envelope-from sgk) Date: Sun, 19 May 2013 10:09:01 -0700 From: Steve Kargl To: David Chisnall Subject: Re: C99 Long Double Math Functions Message-ID: <20130519170901.GA96649@troutmask.apl.washington.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-numerics@freebsd.org" X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 17:38:32 -0000 On Sun, May 19, 2013 at 12:10:28PM -0400, David Chisnall wrote: > Hi Everyone, > > In February, lots of people had code ready to commit for the C99 long double math.h functions. This code is still not in and is an increasingly serious problem for a lot of software. Two weeks from today, I will commit a patch that just calls the double versions of these for all of the long double functions. If you have a better implementation of any of them, please commit it before then. Style nits can be worked out later. Small bugs in corner cases can also be fixed later: it is far worse for us to have no implementation of these than to have a slightly buggy one, because it just drives people to use platforms that have very buggy versions of them instead of FreeBSD. > > David Unfortunately, life gets in the way of hacking on FreeBSD. However, it so happens that I'll be sending a patch to das@ in early June with an expl() update and an implementation for expm1l(). -- Steve From owner-freebsd-numerics@FreeBSD.ORG Sun May 19 18:29:41 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 504A0B8B for ; Sun, 19 May 2013 18:29:41 +0000 (UTC) (envelope-from s.montgomerysmith@gmail.com) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 23E922ED for ; Sun, 19 May 2013 18:29:41 +0000 (UTC) Received: by mail-ia0-f178.google.com with SMTP id i9so6970097iad.9 for ; Sun, 19 May 2013 11:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=U2G216ob912Vw/K6gxR1zHoTgv4ebfR46sKyTNtWECk=; b=vyx1P1gvJDT32rr+Q8eTLXKs8e92Kv5hvvA5UdLPUpxG5AbABsL789fQzah3YY7gYC kQLapNJjiDENYneqzLOEs3bax31yGQzDMxWKn/0Eua65GQ2rofKCxAtoGmWJ4Lau4+wr r4Q1PIvzuQor0LHwg5/MvVZtHeBGsUjJhNKGvx4VidQK3ZjTgsWixwKmGGVoISf3LuSw lZ6lyVZr0/FZC+1/V/Nv7tDpvnl1hT6dUW6LvZYiQp7e49ZUt85t5CjVVBc/FGmd7dX4 NMYk8WZLZ7NKTrVrRUo/Zq5itvmNYP0IB6t+doUgTe/3iSf0rWEXAoYWVGkSi0fYZ8eO 0pGg== X-Received: by 10.50.22.98 with SMTP id c2mr1162081igf.52.1368988180849; Sun, 19 May 2013 11:29:40 -0700 (PDT) Received: from [192.168.0.11] (50-82-246-58.client.mchsi.com. [50.82.246.58]) by mx.google.com with ESMTPSA id o10sm7906826igh.2.2013.05.19.11.29.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 May 2013 11:29:39 -0700 (PDT) Sender: Stephen Montgomery-Smith Message-ID: <51991A10.70103@missouri.edu> Date: Sun, 19 May 2013 13:29:36 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-numerics@freebsd.org Subject: C99 Complex Functions: was: C99 Long Double Math Functions References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 18:29:41 -0000 On 05/19/2013 11:10 AM, David Chisnall wrote: > Hi Everyone, > > In February, lots of people had code ready to commit for the C99 long double math.h functions. This code is still not in and is an increasingly serious problem for a lot of software. Two weeks from today, I will commit a patch that just calls the double versions of these for all of the long double functions. If you have a better implementation of any of them, please commit it before then. Style nits can be worked out later. Small bugs in corner cases can also be fixed later: it is far worse for us to have no implementation of these than to have a slightly buggy one, because it just drives people to use platforms that have very buggy versions of them instead of FreeBSD. > > David > With his Core hat on I have implementations of the complex arc-trig functions. I have been given some style changes. But I would rather someone else take them over and fix the style issues. I think they are ready to be committed even without the style fixes. They are MUCH more accurate than the corresponding Linux versions. http://people.freebsd.org/~stephen/ http://www.math.missouri.edu/~stephen/software/#catrig Also, I think someone has working versions of clog and clogl. Let's light this candle, and get committing. From owner-freebsd-numerics@FreeBSD.ORG Mon May 20 11:06:50 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F04EF5D6 for ; Mon, 20 May 2013 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C8977DB9 for ; Mon, 20 May 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4KB6ogd082983 for ; Mon, 20 May 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4KB6obc082981 for freebsd-numerics@FreeBSD.org; Mon, 20 May 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 May 2013 11:06:50 GMT Message-Id: <201305201106.r4KB6obc082981@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-numerics@FreeBSD.org Subject: Current problem reports assigned to freebsd-numerics@FreeBSD.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/175811 numerics libstdc++ needs complex support in order use C99 o bin/170206 numerics [msun] [patch] complex arcsinh, log, etc. 2 problems total. From owner-freebsd-numerics@FreeBSD.ORG Tue May 21 06:01:13 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CB1B8B4C; Tue, 21 May 2013 06:01:13 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 38D9C1CF; Tue, 21 May 2013 06:01:12 +0000 (UTC) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r4L61C3v017277; Tue, 21 May 2013 16:01:12 +1000 Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r4L611Jr018052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 16:01:04 +1000 Date: Tue, 21 May 2013 16:01:01 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl Subject: Re: C99 Long Double Math Functions In-Reply-To: <20130519170901.GA96649@troutmask.apl.washington.edu> Message-ID: <20130521151407.L1076@besplex.bde.org> References: <20130519170901.GA96649@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.0 cv=e4Ne0tV/ c=1 sm=1 a=XUiGcGvH_TIA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=tJ8Aknsx7QsA:10 a=h8kA8E1_rniwYnuUX4gA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: "freebsd-numerics@freebsd.org" , David Chisnall X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 06:01:13 -0000 On Sun, 19 May 2013, Steve Kargl wrote: > On Sun, May 19, 2013 at 12:10:28PM -0400, David Chisnall wrote: >> Hi Everyone, >> >> In February, lots of people had code ready to commit for the C99 long double math.h functions. This code is still not in and is an increasingly serious problem for a lot of software. Two weeks from today, I will commit a patch that just calls the double versions of these for all of the long double functions. If you have a better implementation of any of them, please commit it before then. Style nits can be worked out later. Small bugs in corner cases can also be fixed later: it is far worse for us to have no implementation of these than to have a slightly buggy one, because it just drives people to use platforms that have very buggy versions of them instead of FreeBSD. >> >> David Please use the unix newline in mail. History shows that style nits rarely get worked out later, and usually increase. > Unfortunately, life gets in the way of hacking on FreeBSD. However, > it so happens that I'll be sending a patch to das@ in early June > with an expl() update and an implementation for expm1l(). Unfortunately, das@ has been inactive since he got his PhD. I spent a half of yesterday so retesting libm for correctness and cleaning up log*. Style problems in log* currently include its layering. I am now trying hacks like multiple includes of __FILE__ to avoid pessimizations and complications from using inline functions. These give worse layering and different complications. If you promise to fix the style "nits" in this (move 100K of code around to perfect places), then it is committable as it is. Bruce From owner-freebsd-numerics@FreeBSD.ORG Tue May 21 11:44:47 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6D9FFE73; Tue, 21 May 2013 11:44:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 51655A53; Tue, 21 May 2013 11:44:47 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r4LBif8x007533; Tue, 21 May 2013 04:44:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r4LBifo5007532; Tue, 21 May 2013 04:44:41 -0700 (PDT) (envelope-from sgk) Date: Tue, 21 May 2013 04:44:41 -0700 From: Steve Kargl To: Bruce Evans Subject: Re: C99 Long Double Math Functions Message-ID: <20130521114441.GA7399@troutmask.apl.washington.edu> References: <20130519170901.GA96649@troutmask.apl.washington.edu> <20130521151407.L1076@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130521151407.L1076@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-numerics@freebsd.org" , David Chisnall X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 11:44:47 -0000 On Tue, May 21, 2013 at 04:01:01PM +1000, Bruce Evans wrote: > On Sun, 19 May 2013, Steve Kargl wrote: > > > Unfortunately, life gets in the way of hacking on FreeBSD. However, > > it so happens that I'll be sending a patch to das@ in early June > > with an expl() update and an implementation for expm1l(). > > Unfortunately, das@ has been inactive since he got his PhD. Well, das@ is still listed as my mentor, so I need approval from him to commit. He did indicate to me that if you approved a patch, I could commit it. Our usual exchange follows: here: 1) I send a (possibly new) diff. 2) you tell me that you've made some refinements to the algorithm(s) or there are style(9) issues. 3) I integrate your changes (where upon I fat finger something to introduce a new style(9) issue). 4) I then spend a week or so testing the changes on i386, amd64, and sparc64. 5) Generate a new diff and send it to bde. 6) Get busy with life. 7) goto here. > I spent a half of yesterday so retesting libm for correctness and > cleaning up log*. Style problems in log* currently include its > layering. I am now trying hacks like multiple includes of __FILE__ > to avoid pessimizations and complications from using inline functions. > These give worse layering and different complications. If you promise > to fix the style "nits" in this (move 100K of code around to perfect > places), then it is committable as it is. > > Bruce -- Steve From owner-freebsd-numerics@FreeBSD.ORG Tue May 21 13:14:37 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1FAC7EBD for ; Tue, 21 May 2013 13:14:37 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id E762CFF0 for ; Tue, 21 May 2013 13:14:36 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r4LDEQTw003493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 13:14:27 GMT (envelope-from theraven@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: C99 Long Double Math Functions From: David Chisnall In-Reply-To: <20130521114441.GA7399@troutmask.apl.washington.edu> Date: Tue, 21 May 2013 14:14:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130519170901.GA96649@troutmask.apl.washington.edu> <20130521151407.L1076@besplex.bde.org> <20130521114441.GA7399@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.1499) Cc: "freebsd-numerics@freebsd.org" , Bruce Evans X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 13:14:37 -0000 On 21 May 2013, at 12:44, Steve Kargl = wrote: > Well, das@ is still listed as my mentor, so I need approval > from him to commit. He did indicate to me that if you approved > a patch, I could commit it. =20 You now have core approval to commit patches that improve the state of = libm. David From owner-freebsd-numerics@FreeBSD.ORG Tue May 21 13:18:13 2013 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 91AB7F3B for ; Tue, 21 May 2013 13:18:13 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 669BE7D for ; Tue, 21 May 2013 13:18:13 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r4LDIBRS003502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 13:18:12 GMT (envelope-from theraven@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: C99 Long Double Math Functions From: David Chisnall In-Reply-To: <20130521151407.L1076@besplex.bde.org> Date: Tue, 21 May 2013 14:18:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: <26E2AF61-03FA-4940-81BA-9166B1370165@freebsd.org> References: <20130519170901.GA96649@troutmask.apl.washington.edu> <20130521151407.L1076@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1499) Cc: "freebsd-numerics@freebsd.org" , Steve Kargl X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 13:18:13 -0000 On 21 May 2013, at 07:01, Bruce Evans wrote: > I spent a half of yesterday so retesting libm for correctness and > cleaning up log*. Style problems in log* currently include its > layering. I am now trying hacks like multiple includes of __FILE__ > to avoid pessimizations and complications from using inline functions. > These give worse layering and different complications. If you promise > to fix the style "nits" in this (move 100K of code around to perfect > places), then it is committable as it is. Is your current code worse than the lack of any implementation? If not, then please commit it. I have no objections to your continuing to improve it after it has been committed, but its lack is currently a blocker for a number of other things. David From owner-freebsd-numerics@FreeBSD.ORG Wed May 22 03:16:27 2013 Return-Path: Delivered-To: numerics@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C1E1AA25; Wed, 22 May 2013 03:16:27 +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 6A0CA2A7; Wed, 22 May 2013 03:16:24 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id DF9253C123D; Wed, 22 May 2013 13:16:15 +1000 (EST) Date: Wed, 22 May 2013 13:16:14 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: numerics@freebsd.org Subject: gdb displays xmm registers poorly on amd64, but works on i386 Message-ID: <20130522122836.H1038@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.0 cv=e4Ne0tV/ c=1 sm=1 a=DCffsqWhnkgA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=Gn94XqwyB2YA:10 a=UNQmailsU6rZeZswHywA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: kib@freebsd.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 03:16:27 -0000 Debugging log* reminded me of some bugs in gdb. First, gdb is still broken on pipelines, so it is harder to demonstrate bugs in it non-interactively: @ Script started on Wed May 22 02:37:41 2013 @ pts/2:bde@freefall:~/s> echo 'p 1' | gdb @ GNU gdb 6.1.1 [FreeBSD] @ Copyright 2004 Free Software Foundation, Inc. @ GDB is free software, covered by the GNU General Public License, and you are @ welcome to change it and/or distribute copies of it under certain conditions. @ Type "show copying" to see the conditions. @ There is absolutely no warranty for GDB. Type "show warranty" for details. @ This GDB was configured as "amd64-marcel-freebsd". @ (gdb) Hangup detected on fd 0 @ error detected on stdin This is because gdb doesn't understand poll(2). It quits when it sees POLLHUP, before reading all the input (FreeBSD sets both POLLIN and POLLHUP when there is hangup but unread input. IIRC, -current is still missing one of my fixes in this area -- when there is hangup but no unread input, POLLHUP should remain set of course, but POLLIN should be declared). @ pts/2:bde@freefall:~/s> cat z @ echo 'p 1' @ echo 'p 2' @ pts/2:bde@freefall:~/s> gdb exit It is even more broken when the input is from a regular file. Now it sees the input and doesn't see hangup, but it messes up the output. @ @ Script done on Wed May 22 02:38:12 2013 gdb used to work for at least piped input when it used select(2) instead of poll(2). With select(), there is no POLLHUP to confuse it, so it must use read() to try to detect EOF. It makes the usual assumption that read() only returns 0 at EOF. This has races in general, but works in simple situations when nothing else can eat the input. A read() is needed for poll() too when POLLIN indicates input too. If poll() is broken and keeps returning POLLIN after hangup when there is no input, then the application must either make the same assumption as for select() and try to detect EOF using read(), or it must assume that poll() is broken in a different way and doesn't set POLLHUP while there is unread input -- then the gdb method works. Now for the xmm display bugs: @ Script started on Wed May 22 02:43:16 2013 @ pts/2:bde@freefall:~/s> gdb /bin/cat @ GNU gdb 6.1.1 [FreeBSD] @ Copyright 2004 Free Software Foundation, Inc. @ GDB is free software, covered by the GNU General Public License, and you are @ welcome to change it and/or distribute copies of it under certain conditions. @ Type "show copying" to see the conditions. @ There is absolutely no warranty for GDB. Type "show warranty" for details. @ This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... @ (gdb) r @ Starting program: /bin/cat @ (no debugging symbols found)...(no debugging symbols found)...^Z @ Program received signal SIGTSTP, Stopped (user). @ 0x00000008009422f8 in read () from /lib/libc.so.7 @ (gdb) p $xmm0 @ $1 = {f = {0, 0, 0, 0}} gdb cannot know the types of the bits in xmm registers, and it is useful to display all types, but on amd64 it only displays the float type. @ (gdb) The program is running. Exit anyway? (y or n) y @ pts/2:bde@freefall:~/s> exit @ @ Script done on Wed May 22 02:43:41 2013 @ Script started on Wed May 22 03:02:03 2013 @ pts/6:bde@ref10-i386:~/s> gdb /bin/cat @ GNU gdb 6.1.1 [FreeBSD] @ Copyright 2004 Free Software Foundation, Inc. @ GDB is free software, covered by the GNU General Public License, and you are @ welcome to change it and/or distribute copies of it under certain conditions. @ Type "show copying" to see the conditions. @ There is absolutely no warranty for GDB. Type "show warranty" for details. @ This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... @ (gdb) r @ Starting program: /bin/cat @ (no debugging symbols found)...(no debugging symbols found)...^Z @ Program received signal SIGTSTP, Stopped (user). @ 0x2818ca65 in read () from /lib/libc.so.7 @ (gdb) p $xmm0 @ $1 = {v4_float = {0, 0, 0, 0}, v2_double = {0, 0}, @ v16_int8 = '\0' , v8_int16 = {0, 0, 0, 0, 0, 0, 0, 0}, @ v4_int32 = {0, 0, 0, 0}, v2_int64 = {0, 0}, @ uint128 = 0x00000000000000000000000000000000} gdb displays all the types on i386. It is bizarre that the xmm display works better on the arch where xmm is less used. @ (gdb) The program is running. Exit anyway? (y or n) y @ pts/6:bde@ref10-i386:~/s> exit @ @ Script done on Wed May 22 03:02:19 2013 gdb displays all the types even on i386 running FreeBSD-~5.2, where ptrace stuff for xmm and i387 registers is different and more deficient than now. I think tags translation for i387 registers is still missing in the kernel. However, for some versions of the kernel on some arches, gdb never fetches the i387 registers directly from the kernel, but fetches the xmm registers and does its own translation of everything including tags to i387. The poor display might be caused by ifdef tangles related to this. Bruce From owner-freebsd-numerics@FreeBSD.ORG Wed May 22 05:03:04 2013 Return-Path: Delivered-To: numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 29C12748; Wed, 22 May 2013 05:03:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id A710888A; Wed, 22 May 2013 05:03:02 +0000 (UTC) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r4M4tUj8008996; Wed, 22 May 2013 14:55:30 +1000 Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r4M4tJJn031018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 May 2013 14:55:21 +1000 Date: Wed, 22 May 2013 14:55:19 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: numerics@freebsd.org Subject: extra-precision bugs in clang on i386 even with __SSE*_MATH__ Message-ID: <20130522131618.M1038@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.0 cv=BPvrNysG c=1 sm=1 a=OBzK9IdsZ0wA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=SnWk4Hs31W4A:10 a=7jRFLMzktCi4NJO2apkA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: dim@freebsd.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 05:03:04 -0000 clang with certain march= in CFLAGS uses SSE for double and/or float operations even on i386 although the ABI doesn't really allow this, and sets __SSE2_MATH__ and/or __SSE_MATH__ to indicate this. It is well known that this breaks the definitions of float_t, double_t and FLT_EVAL_METHOD, because FreeBSD headers haven't been updated to support clang; in particular they know nothing of __SSE*_MATH__. I recently noticed a related bug that is not due to missing support in FreeBSD. Like gcc, clang doesn't discard extra precision on casts or assignments, as is fuzzily specified in C90 and explicitly specified in C99). Using SSE breaks extra precision by preventing it from occurring in most cases, but it can still occur if a double or float is somehow allocated in an i387 register. This occurs mainly for function calls, because the ABI requires FP functions to return results in extra-precision registers, and it is normal and normally good to actually return extra-precision results. clang then fails to clip the extra precision even when explicitly requested to do so using a cast or assignment. E.g. @ #include @ #include @ @ static double tiny = 0x1p-31; @ @ int @ main(void) @ { @ printf("tiny = %a\n", tiny); @ printf("cos(tiny) may have extra precision, and is %La\n", @ (long double)cos(tiny)); @ printf("(double)cos(tiny) should be 1, but is %La\n", @ (long double)(double)cos(tiny)); @ return (0); @ } This works correctly on amd64 (amd64 happens not to use i386 fcos, but even if it did then the extra precision in the fcos result would be clipped by the ABI returning the result in an xmm regiser), but on i386 it gives: @ tiny = 0x1p-31 @ cos(tiny) may have extra precision, and is 0x1.fffffffffffffffcp-1 @ (double)cos(tiny) should be 1, but is 0x1.fffffffffffffffcp-1 Both results are just (1 - (long double)tiny * tiny / 2) rounded to long double precision. It is normally good for cos(tiny) to have extra precision, so that you can use it in double precision expressions that produce extra-precision results according to FLT_EVAL_METHOD. Without this, you can't write even the squaring operation x*x as a function that returns x*x, without the function being unnecessarily less accurate and giving different results than the expression x*x or a function-like macro that gives x*x. Similarly for all functions that return double or float. However, sometimes you need to clip the extra precision, and compiler bugs make this difficult to do in a standard way. Normally the compiler bugs are features because the clipping operation is slow, and naive code that assigns intermediate results to double and float variables will lose precision and speed unnecessarily (non-naive code must use float_t and double_t for almost everything and clip these only when necessary. This works well except across function calls). FreeBSD libm uses the STRICT_ASSIGN() macro to do clipping. It only does explicit clipping if FLT_EVAL_METHOD != 0 (or !__GNUC__). The present bug prevents fixing FLT_EVAL_METHOD to be 0 with clang using SSE*, since that would break STRICT_ASSIGN() in the case where the rvalue has extra precision because it is allocated in a register. It is difficult to make STRICT_ASSIGN() depend on the register allocation even in a nonstandard way. C11 breaks this area even more. It specifies that extra precision is always clipped on return, at least in C functions. This breaks intentionally returning extra precision for accuracy, and more seriously it breaks efficiency by requiring the slow clipping operation on every return (on x86, the clipping operation takes about as long as 2 serially-dependent addition operations and stalls pipelines due to its serial dependencies). Buggy compilers should ignore this buggy specification like they already ignore the buggy specification to clip precision on casts and assignments. Clipping on every assignment is even more inefficient because assignments are more common than returns. However, there needs to be a standard way to clip (just casting?). I don't know if this applies to library functions implemented in another language. If it does, then all libraries that use raw hardware functions like i387 fcos are non-conformant, and must be weakened for conformance. C99's bugs in this area give the bizarre requirement that extra precision must be clipped on return if and only if it was gained intentionally (literally, if and only if it is explicit, but implementations that generate it intentionally will probably have it explicitly). The C11 regression is a apparently a reaction to this bizarreness. Examples: 1. double sq(double x) { return (x * x); } 2. double sq(double x) { return ((long double)x * x); } 3. double sq(double x) { return ((double_t)x * x); } (1) may evaluate x*x in implicit extra precision according FLT_EVAL_METHOD. If it did, then it should return the extra precision. C99 permits this, but C11 doesn't. (2) evaluates x*x in explicit higher precision (which is strictly higher iff long double is strictly larger). Neither C99 nor C11 permit returning the extra precision, if any. (3) evaluates x*x in explicit minimally-for-efficiency extra precision. Neither C99 nor C11 permit returning the extra precision, if any. So the most careful code that uses double_t to keep as much extra precision as possible (subject to efficiency) is required to waste time to kill this care at function call boundaries. I use a fake null cast of double_t to double (using null asm) to avoid the losses in (3). This works with gcc but not with clang. clang seemed to implement part of the C11 breakage and added clipping code even for converting a type to the same type. In numeric terms, for a certain version of logf on certain hardware, the clipping costs were approximately: - gcc version on i386 with no clipping: ~35 cycles/call - clang version on i386 with clipping: ~35+8 cycles/call - gcc and clang versions on amd64: ~35+8 cycles/call amd64 was slower because the ABI enforces clipping. The cycle counts were not precisely the same for the clipping versions on the different arches, but the clipping cost is 8 cycles on both and this dominates all the other differences (using SSE and a cleaner ABI on amd64 makes remarkbly little difference). Investigating the clang difference now showed futher bizarreness: - neither clang nor gcc do the clipping required by C99 for (2) or (3). This is apparently because thet know that upcasting x doesn't change it but don't know that upcasting x may change the result of the expression. - however, both gcc and clang do the clipping for: (3'). double prod(double x, long double y) { return (x * y); } Here is my asm hack that doesn't work for clang: @ /* @ * Convert a float_t to a float without losing extra precision and/or @ * wasting time, if possible. This is a sort of inverse for @ * STRICT_ASSIGN(). It is typically used to avoid C's bizarre return @ * semantics, which require that extra precision intentionally obtained by @ * using float_t within the function must be lost on return, while extra @ * precision accidentally obtained by using float within the function may @ * be kept on return. @ */ @ static inline float @ hackfloat_t(__float_t ft) @ { @ #if defined(__i386__) && !defined(__SSE_MATH__) @ float f; @ @ __asm("" : "=t" (f) : "0" (ft)); @ return (f); @ #else @ return (ft); @ #endif @ } @ @ /* Similarly for double_t. */ @ static inline double @ hackdouble_t(__double_t dt) @ { @ #if defined(__i386__) && !defined(__SSE2_MATH__) @ double d; @ @ __asm("" : "=t" (d) : "0" (dt)); @ return (d); @ #else @ return (dt); @ #endif @ } @ Changing (x * y) to hackdouble_t(x * y) fixes the lost accuracy and speed only for gcc. Bruce From owner-freebsd-numerics@FreeBSD.ORG Wed May 22 08:51:22 2013 Return-Path: Delivered-To: numerics@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0371EEB9; Wed, 22 May 2013 08:51:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 971B134A; Wed, 22 May 2013 08:51:21 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4M8pHN6076595; Wed, 22 May 2013 11:51:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4M8pHN6076595 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4M8pHYk076594; Wed, 22 May 2013 11:51:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 22 May 2013 11:51:17 +0300 From: Konstantin Belousov To: Bruce Evans Subject: Re: extra-precision bugs in clang on i386 even with __SSE*_MATH__ Message-ID: <20130522085117.GK3047@kib.kiev.ua> References: <20130522131618.M1038@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RrBt8QUUAk8/lIok" Content-Disposition: inline In-Reply-To: <20130522131618.M1038@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: dim@freebsd.org, numerics@freebsd.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 08:51:22 -0000 --RrBt8QUUAk8/lIok Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Only replying to some secondary points in the message. On Wed, May 22, 2013 at 02:55:19PM +1000, Bruce Evans wrote: > clang with certain march= in CFLAGS uses SSE for double and/or float > operations even on i386 although the ABI doesn't really allow this, > and sets __SSE2_MATH__ and/or __SSE_MATH__ to indicate this. It is > well known that this breaks the definitions of float_t, double_t and > FLT_EVAL_METHOD, because FreeBSD headers haven't been updated to support > clang; in particular they know nothing of __SSE*_MATH__. Hm, i386 ABI is silent about XMM registers use, which means that the registers are caller-saved, if available. And it cannot mandate the non-use of any processor instructions at all. ABI-conformant code could use any supported CPU instruction (and unsupported as well, if the SIGILL is the intended outcome). > C11 breaks this area even more. It specifies that extra precision is > always clipped on return, at least in C functions. This breaks > intentionally returning extra precision for accuracy, and more seriously > it breaks efficiency by requiring the slow clipping operation on every > return (on x86, the clipping operation takes about as long as 2 > serially-dependent addition operations and stalls pipelines due to > its serial dependencies). SSE conversions like CVTSD2SS are very fast. According to the Agner Fog tables, on the SandyBridge-class CPU, the instruction has the latency of 3 and new CVTSD2SS instruction can be started on each cycle. This is comparable with the simple integer arithmetic. --RrBt8QUUAk8/lIok Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRnIcFAAoJEJDCuSvBvK1BzcQP/i5mXTSYNe0/gt2nrrFIGlk2 QlhpYKw64iQmnQzTqJVUvdM39fSJGklP5l3lTweQRTxvMdmL+JMQeTF1SK99pfCt 4X2Nnk60uZbuodsICLIgkwvudfhCDJ+QJC/Kr1R1yaRrw0DZpt/+MBZ01r9mLhWd 4WdAylpGeKDS/7TkLdvObZMMPgIfdfqC0L0xgs/OCfowl2OVlFB4EJAWGwvoUEou AtVhunMhpWGOzuHsBojK6yI3m0LwU1zjzqcO9dxuYVwuP8giSLb7x9uwN8kMoWd/ GErtkjLCmMboTH3g9lIbdbTvGASLiiN7gx0Hcr2E03HnnQuCbcC0xP2gEfT3cPxQ w6EBBNFac0ZCNnOslOr0PvLB8L9asSIPq4MP+YfOBlmodxfnGLRXeR0NkY6zyERX HBk9eKGT9OEWEaN7KFlTBONJm/oyyr6p2MtCnOHOKR7xcMOempXu6xijdhEcbuC5 Q8HQI9LAzLu69s5u1PYrjYdfTKaWZHPTtQOMqM7G82rAiwCDSku02sFL3E07X0oY o6o4T1GgL/h7ioBmHbiFpLda3wyYU6HP81tpCfTUfct12k7KUnHKd4TUDAIimLvo uh/Cj8EvAlQrqLpZs5oJJmnahMJKJi0+syiWgTja6D5FmCUg2FEfPf65rlSN5fKU KF8nszrZVvrNky+H+BSI =nc5Z -----END PGP SIGNATURE----- --RrBt8QUUAk8/lIok-- From owner-freebsd-numerics@FreeBSD.ORG Thu May 23 06:38:41 2013 Return-Path: Delivered-To: numerics@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6E4C85C3 for ; Thu, 23 May 2013 06:38:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D89C383E for ; Thu, 23 May 2013 06:38:40 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4N6cbCQ080816; Thu, 23 May 2013 09:38:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4N6cbCQ080816 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4N6caAk080815; Thu, 23 May 2013 09:38:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 23 May 2013 09:38:36 +0300 From: Konstantin Belousov To: Bruce Evans Subject: Re: gdb displays xmm registers poorly on amd64, but works on i386 Message-ID: <20130523063836.GT3047@kib.kiev.ua> References: <20130522122836.H1038@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4s9hgdIji3nAkoPB" Content-Disposition: inline In-Reply-To: <20130522122836.H1038@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: numerics@freebsd.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 06:38:41 -0000 --4s9hgdIji3nAkoPB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, May 22, 2013 at 01:16:14PM +1000, Bruce Evans wrote: > gdb displays all the types even on i386 running FreeBSD-~5.2, where ptrace > stuff for xmm and i387 registers is different and more deficient than now. > I think tags translation for i387 registers is still missing in the kernel. > However, for some versions of the kernel on some arches, gdb never fetches > the i387 registers directly from the kernel, but fetches the xmm registers > and does its own translation of everything including tags to i387. The > poor display might be caused by ifdef tangles related to this. The gdb 7.6 on amd64 displays all representations of the xmm registers, as well as decodes the mxcsr bits: xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000} ... mxcsr 0x1f80 [ IM DM ZM OM UM PM ] I did not verified if the last gdb learned to display YMM on AVX-capable kernels, both for 32 and 64 bits. --4s9hgdIji3nAkoPB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRnblrAAoJEJDCuSvBvK1BsuIP/RPFa3fta2h9yHWi2CDAs4xP 3EuzKne3D3XRL7iRuzv+bPYJVIgBEc3tBQmftDY3NgwlecfsCliyNVp04i+s+zF5 bNuIchePDP9Kg49GwYqKzMsnYDEuO31Te+6fvSRXDLPfBqvl8qLrq+bVBYGDgRag LhQAc+IvDCsJnhtWk5ze6ORNoUlScp1ZTmKZ1l/gNuPHaJJQbaT6ViLZt7HqLdju 0zlOmm+9nvyDmpWz8vBZ2BH9wJbK25RxPX2KnNYyKVLmYauYGSrSnDp5fj5jn+Rx d0b2opyytktKvy8n4TuA0i2ORIJhjLUsyjKxbhHO4Eoe5vMi9rZmISVO+kgGWTtE oulHET9iM6kAbYIthPFb98pWX/NrQO1HLK4/BV17iEe1yVnO2BoV8wJ3Ekhn94tq nTbNnbMtfXd7exxtwzp2htbubBDbC9TCuSEq17oZ/5JbL06xviACHRUKVgOiVRLv DjTQjFWQBv2qGnFQFEA7G6gQ++Ih2aMwEN/ApEN57ONmptcPCJZ4v0kOrM60xlAM B6HzJVwaXiz1SwGX67PTZUVGCMGZqI/lZ/Rq/DsrhZGS24OwElqeMInrpTZGPTP2 qMFiHoLTEpaYIIVKbj9DUd1/5GpiFlO0d0mAHiXZOYf9mrBhwqZ7MBBwGusD0u2o RkrEAoSnld1DyhOd8Cgn =gFfe -----END PGP SIGNATURE----- --4s9hgdIji3nAkoPB-- From owner-freebsd-numerics@FreeBSD.ORG Fri May 24 08:07:08 2013 Return-Path: Delivered-To: numerics@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD9B6140; Fri, 24 May 2013 08:07:08 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2026DD; Fri, 24 May 2013 08:07:07 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r4O86v8A012253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 May 2013 18:06:59 +1000 Date: Fri, 24 May 2013 18:06:57 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: numerics@freebsd.org Subject: clang crash on "x" constraint for athlon-xp Message-ID: <20130524173835.T2001@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.0 cv=e/de0tV/ c=1 sm=1 a=52lMFrBwFFYA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=iyYjl1V9ma8A:10 a=Twlkf-z8AAAA:8 a=MrvP7jtUUPqbAPXLnmwA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: dim@freebsd.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 08:07:08 -0000 Why does clang -march=athlon-xp abort on this? @ #include @ @ void @ foo(void) @ { @ __m128 x; @ @ asm("" : "=x" (x)); @ } @ SplitVectorResult #0: 0x2a190228: v16i8 = Register %vreg1 [ORD=1] [ID=0] @ @ fatal error: error in backend: Do not know how to split the result of this operator! @ @ cc: error: clang frontend command failed with exit code 70 (use -v to see invocation) @ FreeBSD clang version 3.3 (trunk 178860) 20130405 @ Target: i386-unknown-freebsd10.0 @ Thread model: posix @ cc: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. @ cc: note: diagnostic msg: @ ******************** @ @ PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: @ Preprocessed source(s) and associated run script(s) are located at: @ cc: note: diagnostic msg: /tmp/z-SmXpwL.c @ cc: note: diagnostic msg: /tmp/z-SmXpwL.sh @ cc: note: diagnostic msg: @ @ ******************** clang also fills up /tmp with these files. gcc -march=athlon-xp works, and so does clang -march=athlon64. athlon64 has SSE1 and SSE2; athlon-xp only has SSE1. The above is trying to use only SSE1 features. I don't really understand and am using it here just to declare __m128. Perhaps it can do what I want without any asm. This is to take an 8-byte double and split it into 2 integers using SSE*, and vice versa. SSE* must be used on 32-bit systems since compilers still don't understand how to unpack and repack 64-bit objects efficiently using integer instructions (loads and stores must be 64 bits). I also need this for 10-byte long doubles. Raw asm is needed for 2 bytes of these, and it would be hard to combine this with any intrinsics. While here, I will re-report another clang asm problem: @ double_t dt; @ double d; @ @ __asm("" : "=t" (d) : "0" (dt)); This works with gcc, but fails (generates a store-load of d, but the whole point of this null asm is to avoid this store-load by pretending that the asm does it) with clang. If the constraints are changed to "=&t" and "t", then it works for clang but fails (with constraint and/or reload errors) with gcc. Bruce From owner-freebsd-numerics@FreeBSD.ORG Fri May 24 15:06:56 2013 Return-Path: Delivered-To: numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 95624BE8; Fri, 24 May 2013 15:06:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 62989816; Fri, 24 May 2013 15:06:56 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r4OF6o8o027237; Fri, 24 May 2013 08:06:50 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r4OF6oEa027236; Fri, 24 May 2013 08:06:50 -0700 (PDT) (envelope-from sgk) Date: Fri, 24 May 2013 08:06:50 -0700 From: Steve Kargl To: Bruce Evans Subject: Re: clang crash on "x" constraint for athlon-xp Message-ID: <20130524150650.GA27216@troutmask.apl.washington.edu> References: <20130524173835.T2001@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130524173835.T2001@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dim@freebsd.org, numerics@freebsd.org X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 15:06:56 -0000 On Fri, May 24, 2013 at 06:06:57PM +1000, Bruce Evans wrote: > Why does clang -march=athlon-xp abort on this? > You probably need to send this type of email to the toolchain email list. I doubt any of the toolchain guys subscribe to the numerics list. Yes, I saw that you cc'd dim@ -- Steve