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]

Re: [fortran,patch] Inline intrinsics: EXPONENT, FRACTION, NEAREST, RRSPACING, SET_EXPONENT and SPACING


FX Coudert wrote:
> Hi all,
> 
> Currently, the intrinsics listed in the subject of this mail are
> translated into calls to library functions in libgfortran. These
> functions are short, and call in turn the system math library functions
> like nextafter(), frexp(), ldexp(), fabs() and scalbn(). This patch
> makes us directly emit that code from the front-end. This allows for
> better optimization and probably better vectorization. I'm not proposing
> the removal of the library functions yet, because that would break ABI
> compatibility; next time we break it for some other reason, however,
> expect me to ask for their removal.

Hmm, I started thinking about doing a patch like this when I read your
cpow->BUILTIN_CPOW patch. Seems you got there first. :)

Anyway, a couple of observations/questions.

1. In libgfortran/nearest, there is a glibc bug workaround:

GFC_REAL_4
nearest_r4 (GFC_REAL_4 s, GFC_REAL_4 dir)
{
  dir = copysignf (__builtin_inff (), dir);
  if (FLT_EVAL_METHOD != 0)
    {
      /* ??? Work around glibc bug on x86.  */
      volatile GFC_REAL_4 r = nextafterf (s, dir);
      return r;
    }
  else
    return nextafterf (s, dir);
}

Has this been fixed in glibc, and even if it has, is the fix recent
enough that we want to support older glibc versions as well? Or perhaps
more to the point, does anyone on glibc/x86 actually compile libgfortran
with FLT_EVAL_METHOD != 0, and if so, why?

2. You use both ldexp and scalbn. AFAICS scalbn does not provide any
added value since in all cases FLT_RADIX is 2 which makes it equivalent
to ldexp (if we ever want to support non-binary FP there are lots of
other changes that have to be made as well). As for which one should be
chosen, ldexp is C89, ldexpf, ldexpl and scalbn* are C99, so I don't
think it makes much difference from a portability standpoint. I just
think it's not that useful to have both.

-- 
Janne Blomqvist

Attachment: signature.asc
Description: OpenPGP digital signature


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