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
