From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30803 invoked by alias); 7 Jun 2016 06:54:20 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 30792 invoked by uid 89); 7 Jun 2016 06:54:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*Ad:D*ru X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Jun 2016 06:54:18 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0537C811DF; Tue, 7 Jun 2016 06:54:17 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-51.ams2.redhat.com [10.36.116.51]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u576sEKv009577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Jun 2016 02:54:16 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u576sDPo014048; Tue, 7 Jun 2016 08:54:13 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u576sAef014047; Tue, 7 Jun 2016 08:54:10 +0200 Date: Tue, 07 Jun 2016 06:54:00 -0000 From: Jakub Jelinek To: Joseph Myers Cc: Thomas Schwinge , gcc-patches@gcc.gnu.org, Alexander Monakov Subject: Re: [PING] [PR other/70945] Handle function_glibc_finite_math in offloading Message-ID: <20160607065410.GL7387@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <87vb27tnai.fsf@hertz.schwinge.homeip.net> <87lh2mqqm8.fsf@kepler.schwinge.homeip.net> <20160603144915.GI7387@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00441.txt.bz2 On Mon, Jun 06, 2016 at 09:11:18PM +0000, Joseph Myers wrote: > On Fri, 3 Jun 2016, Jakub Jelinek wrote: > > > On Fri, Jun 03, 2016 at 04:44:15PM +0200, Thomas Schwinge wrote: > > > Hi! > > > > > > Ping. > > > > I think it would be better to just add this support to newlib. > > That suggestion doesn't really make sense to me. Why should newlib be > expected to follow the same choices as glibc regarding what variants of > libm functions to export, beyond the standard names for those functions, > or how to name any variants it does export? I'm not saying newlib in general, let newlib do whatever they want, but I'm talking about offloading port(s) of newlib, which IMHO should provide translation layer from the host headers to the offloading target functions. The thing is, I think it is much better to have this layer in a source form where you can easily modify it than inside of the compiler where you have to hardwire everything in there. It could sit in some offloading directory of newlib, which the offloading port(s) could share. The __*_finite functions aren't the only one, what if glibc the next half a year adds another 4-5 of the finite math functions? What about e.g. -D_FORTIFY_SOURCE=2 string functions, etc.? Jakub