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] |
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] |