Re: [fortran, patch] IEEE intrinsic modules (ping)

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

I meant to look this over this weekend.  Unfortnately, baseball
and soccer (both daughter and USA vs Portugal) got in the way.
First issue, 

cd gcc4x
patch < ieee_withregenerated_2.diff
...
--------------------------
|Index: configure.host
|===================================================================
|--- configure.host     (revision 211688)
|+++ configure.host     (working copy)
--------------------------
File to patch: libgfortran/configure.host
Patching file libgfortran/configure.host using Plan A...
patch: **** malformed patch at line 939: then

As I don't have a top-level configure.host, I guessed that
libgfortran/configure.host was the right file.

All other parts of the patch applied cleanly.

-- 
steve

On Mon, Jun 23, 2014 at 10:39:30AM +0200, FX wrote:
> ping*2
> 
> I understand the size of the patch can be somewhat off-putting, but given its nature it?s rather hard to split it further. Moreover, apart from the OS-specific bits on the library side, it?s not very difficult. If it is hard for anyone to find time to review it in full, may I suggest that it be given a lighter review before commit? then while it gets some real exposure from users/testers, further review can be performed.
> 
> FX
> 
> 
> 
> 
> > ping for the IEEE patch.
> > 
> > Since last time, I incorporated Uros? comments on the libgfortran/config/fpu-387.h part, and add some documentation to the manual (list of supported targets, and required compilation flags for full IEE support).
> > 
> > OK to commit?
> > I?d really like to get this into trunk, so it can get some exposure to iron it out?
> > 
> > FX
> > 
> > 
> > 
> >> Hi,
> >> 
> >> Last November, I worked on a patch to add the IEEE intrinsic modules to gfortran (thread starting at 
> >> https://gcc.gnu.org/ml/fortran/2013-11/msg00126.html
> >> ). After a round of review, I continued working on it, then didn?t have time, then development was frozen? Now, I found some time to get back to it, and here?s a more complete patch. I?ve bootstrapped it and regtested on:
> >> 
> >>  ? x86_64-linux (both 32-bit and 64-bit); this also uses 387/SSE assembler
> >>  ? x86_64-linux with tweaked configure.host to force it to use glibc functions in config/fpu-glibc.h (both 32-bit and 64-bit)
> >> 
> >> The current state of the patch: as far as I can tell, nearly full support. In particular, since my last patch, I?ve added ?saving/restoring FPU state on procedure entry/exit, when IEEE is used?. This is done in trans-decl.c, by wrapping each affected function body between calls to the library:
> >> 
> >>  try
> >>    {
> >>      _gfortran_ieee_procedure_entry ((void *) &fpstate.0);
> >>      /* procedure body goes here */
> >>    }
> >>  finally
> >>    {
> >>      _gfortran_ieee_procedure_exit ((void *) &fpstate.0);
> >>    }
> >> 
> >> 
> >> 
> >> What?s missing:
> >> 
> >>  0. Gradual underflow control is implemented as "not supported by the processor" (its SUPPORT function returns false, and the GET and SET procedures abort if you call them). That?s explicitly allowed by the standard, so it?s not actually ?missing". We can improve on this in the future, if people can help.
> >> 
> >>  1. Documenting the flags necessary for full IEEE compatibility: it seems that "-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans? is good, but I?ll have to check that with the floating-point middle-end experts. That?s next on my list: documenting our support, and interaction with compilation flags.
> >> 
> >>  2. Your review of the patch!
> >> 
> >> 
> >> I really think getting IEEE support early in stage 1 will benefit the compiler, through good testing before release. I?d like to get this in, but I don?t intend to disappear afterwards? though I?m not stepping back ?full time? into the team, I will be there to fix IEEE bugs and issues.
> >> 
> >> OK to commit?
> >> 
> >> FX
> 
> 





-- 
Steve