ping
> Hi all, > > The attached patch improves our code generation for some of the > IEEE_ARITHMETIC functions: some testing functions (is*) and some arithmetic > (logb, rint, scalb, …). The interfaces are still present in the module file > generated as part of the library (which allows, in particular, for accurate > testing of the extent of support we have), but we catch them before emitting > the actual function call and emit front-end-generated code instead. This code > uses some intrinsics that we didn’t use in the front-end so far (some type > generic, some not), so I have added them (logb, remainder, rint, signbit). > > The patch is nice because it improves the quality of the code generated, > eliminating in many cases the need for a function call. It is also a > prerequisite to extend our IEEE support to more floating-point types > (extended precision and binary128, on some targets including i386/x86_64). > Without it, we would have a combinatorial explosion of the number of “helper” > functions in the library. > > Also, I’m removing symbols from gfortran.map, but no branching/release has > occurred since I added them in the first place: it should be all good. > > Regtested on x86_64-apple-darwin14. This regresses ieee_2.f90, at -m32 > -fno-float-store only, where we seem to trigger a missimplification of > __builtin_rint(). I’ll send, just after this one, a mail to gcc to get some > help on that, and track the issue separately. > > OK to commit? > FX
ieee.ChangeLog
Description: Binary data
ieee.diff
Description: Binary data
