Hi!
Currently there are the following builtins available from the fortran
frontends:
/* We define these separately as the fortran versions have different
semantics (they return an integer type) */
gfc_define_builtin ("__builtin_roundl", mfunc_longdouble[0],
BUILT_IN_ROUNDL, "roundl", true);
gfc_define_builtin ("__builtin_round", mfunc_double[0],
BUILT_IN_ROUND, "round", true);
gfc_define_builtin ("__builtin_roundf", mfunc_float[0],
BUILT_IN_ROUNDF, "roundf", true);
gfc_define_builtin ("__builtin_truncl", mfunc_longdouble[0],
BUILT_IN_TRUNCL, "truncl", true);
gfc_define_builtin ("__builtin_trunc", mfunc_double[0],
BUILT_IN_TRUNC, "trunc", true);
gfc_define_builtin ("__builtin_truncf", mfunc_float[0],
BUILT_IN_TRUNCF, "truncf", true);
note that if they indeed return an integer value, the corresponding
BUILT_IN_LROUND or BUILT_IN_LLROUND builtin codes should be used to
not confuse folding routines. I suppose there is support in
libgfortran for the libcall fallbacks, or are they taken from
libm? In this case they return a floating point value and I'm
confused by the comment above.
I'm currently prototyping a patch to fold (long)round(x) to lround(x)
which, with an appropriate optab for lround should improve lucas SPEC
quite a bit. The patch is working for C99, but currently fails for
fortran because the (l)lround builtins are not available from the
fortran frontend. Lucas uses dnint a lot, which is expanded to
(int)round(x) by the fortran FE, while it looks like it should expand
to lround(x) instead (if the above comment is indeed correct).
Please give me some advice on the fortran semantics of round and
the interaction with the middle-end here.
Thanks,
Richard.
