Ok, thanks for the patch! On Sat, Oct 4, 2014 at 12:55 PM, FX <fxcoud...@gmail.com> wrote: > 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 >
-- Janne Blomqvist
