This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Closing a few libgfortran bugs?


Hi all,

I've been looking into the open libgfortran PR and though I think the
library is rather stable these days, there are 15 open bugs and 11
enhancements. Some of them have been inactive for a while, and I'm not
sure of their status. Some of them should, IMHO, be closed. Here is a
list of PR I'd like to close, or PR for which we could get comments.

  -- 21226 "unix_stream small_buffer unaligned": (Alignment issues are
something I've never completely grasped.) Apparently, there is a way
to improve performance of access to this buffer, but it's a bit
intrusive (adding attributes all over the place). Could someone look
into it? Can we easily do some benchmarking to check whether it's
worth the pain?

  -- 21881 "Array descriptors limit derived type sizes": We could
improve and have derived types get a separate field for the size; in
all cases, we currently emit an internal error for large arrays, we
need at least to turn that into an error message. I'd like to switch
that bug into the front-end category.

  -- 22307 "Missing tests for actual library functions": The original
idea of adding a standalone testsuite for the library seems somehow
not very popular (I, for one, don't think it's convenient). The
current gfortran testsuite also stresses the library, and we uses
temporaries and functions to avoid the simplification routines
stepping in. Close as WONTFIX?

  -- 26253 "fallback scalbn doesn't handle denormals correctly": On
platforms which don't have scalbn, we provide a fallback version, but
this fallback doesn't handle denormals correctly. While this is a
generic problem somehow, most targets have scalbn (currently, this
only shows, I think, on hppa-hpux with older versions of HPUX) and
even there, it's only for denormals. Fixing it would probably mean
writing careful code with assertions about the floating-point models.
I think it's not worth it, and would like to close it as WONTFIX (and
add a comment on top of our scalbn fallback).

  -- 30780 "FPE in CPU_TIME (and possibly others) with
-ffpe-trap=underflow": This one needs a decision. On one hand, working
around it would probably be a hack, but on the other hand,
-ffpe-trap=underflow is basically useless if it creates FPE in the
library. Ideas?


All comments are welcome, and I sure will not commit before I head
from our libgfortran "resident experts", namely Jerry, Thomas and Jane
(hey guys, do you like your new title?).

Thanks, and open fire!
FX


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]