This is the mail archive of the
mailing list for the GCC project.
Re: [RFC Patch]: Implement remainder() as built-in function [PR fortran/24518]
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Uros Bizjak" <ubizjak at gmail dot com>
- Cc: "GCC Patches" <gcc-patches at gcc dot gnu dot org>, "FX Coudert" <fxcoudert at gmail dot com>
- Date: Mon, 23 Oct 2006 13:41:18 +0200
- Subject: Re: [RFC Patch]: Implement remainder() as built-in function [PR fortran/24518]
- References: <email@example.com>
On 10/23/06, Uros Bizjak <firstname.lastname@example.org> wrote:
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
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
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
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?