[PING] [PR other/70945] Handle function_glibc_finite_math in offloading

Jakub Jelinek jakub@redhat.com
Tue Jun 7 06:54:00 GMT 2016


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



More information about the Gcc-patches mailing list