This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [RFC Patch]: Implement remainder() as built-in function [PR fortran/24518]


On 10/23/06, Uros Bizjak <ubizjak@gmail.com> wrote:
Hello!

The motivation for this RFC patch is comment #4 to PR fortran/24518,
where MOD and MODULO fortran calls are proposed to be implemented
using __builtin_fmod() and __builtin_remainder().

Currently there are some obstacles in the implementation of fortran
front-end support:

1) missing __builtin_remainder() optab description (solved by attached patch)

2) __builtin_fmod(), __builtin_drem() and __builtin_remainder()
expansion currently depends on flag_unsafe_math_optimizations, but IMO
there is no reason for that.

Attached patch expands these three builtin functions in all cases.
Errno handling is implemented in the same way as sqrt?f2 support is
handled. The return of intrinsic x87 function is checked for NaN, and
in case NaN is detected, library function is called.

I wonder how we want to deal with the errno mess in general here. The C standard actually most of the time allows setting errno but does not require it (like for fmod - sqrt is an exception to this) and glibc for example does never set errno in these cases. I understand that the ideal semantics of -fno-math-errno is to match the installed library, but inserting library calls is costly and may not even be possible (like for lrint, where a check for NaN is not possible).

Do we want to disable inline expansion of, say, lrint completely if
-fmath-errno is
set?  Would it be ok to not set errno where the standard does not
require it, but
the library sets it even for -fmath-errno?

Thanks,
Richard.


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