[RFC] Support of IEEE modules, first draft for comments

[N.M. Maclaren]

On Nov 10 2013, FX wrote:
>
> Full IEEE support is very complex, and will require cooperation between 
> front-end, middle-end, and libc. Getting every aspect covered is clearly 
> a multi-year project, which will have to be tackled with middle-end and 
> target-savy developers: IEEE support is not excellent in GCC, see for 
> example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

I have just posted a response :-(

Please could you add the interaction with OpenMP to your task list?
I am familiar with all of the relevant standards and issues, and will
try to get a summary back.  It's not pretty :-(

> I've written two versions of the target-specific code, one using glibc 
> APIs and one using assembly for all i386/x86_64 targets. On other 
> targets, the modules are simply not built. This is controlled by 
> libgfortran/configure.host, so if targets want to opt out we can simply 
> list them there. If new targets want to opt in (AIX or SYSV APIs, for 
> example), they need to support the new functions in 
> libgfortran/config/fpu-*.h
>
> Also, I have not yet done thorough testing of the IEEE arithmetic 
> functions (IEEE_LOGB, IEEE_NEXT_AFTER, IEEE_REM, IEEE_RINT, IEEE_SCALB), 
> but this is the next item on my list.

Are you sure?  As I posted earlier, there is a significant chance that
setting a rounding mode flag will break some of the intrinsics; I have
no idea how whether any targets currently generate such code, but it
can't be ruled out.  I will try to draft what I feel should be checked;
I am pretty sure that one could get 99% coverage pretty easily.

The bigger issue of breaking precision extension and such intrinsics
written in user code is much harder, but the code is processor dependent,
anyway.


Regards,
Nick Maclaren.