This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Gfortran didn't support ABS intrinsic?
Steve Kargl wrote:
> On Mon, Nov 17, 2008 at 03:53:58PM +0800, Tianwei wrote:
>> On Mon, Nov 17, 2008 at 2:06 PM, Steve Kargl
>> <sgk@troutmask.apl.washington.edu> wrote:
>>> On Mon, Nov 17, 2008 at 01:22:40PM +0800, Tianwei wrote:
>>>> the test is "xlintstz" which is for double precison complex liner
>>>> equation. Other compiler all did this optimization by default, also
>>>> there is an intrinsic statement in the .f file:
>>>> zlange.f:
>>>> 83 * .. Intrinsic Functions ..
>>>> 84 INTRINSIC ABS, MAX, MIN, SQRT
>>> What's your point? gfortran correctly recognizes ABS as
>>> an intrinsic procedure. gfortran may call a library
>>> routine for CABS where it is expected that CABS correctly
>>> handles rounding/overflow issues.
>>>
>> My point is that why other compiler all set "-ffast-math" by default,
>> and the user don't have to specify "-ffast-math " to enable this
>> intrinsic. Maybe it's an unsafe optimizaiton, if this is the case,
>> other compiler shouldn't enable them at -O3 level by default.
>>
>
> Other compilers that have an option equivalent to -ffast-math
> and set by default are probably trying to score well on
> benchmarks to improve their sales. -ffast-math may cause
> wrong results. From the gcc manual,
>
> `-ffast-math'
> Sets `-fno-math-errno', `-funsafe-math-optimizations',
> `-ffinite-math-only', `-fno-rounding-math', `-fno-signaling-nans'
> and `-fcx-limited-range'.
>
> This option causes the preprocessor macro `__FAST_MATH__' to be
> defined.
>
> This option is not turned on by any `-O' option since it can
> result in incorrect output for programs which depend on an exact
> implementation of IEEE or ISO rules/specifications for math
> functions. It may, however, yield faster code for programs that do
> not require the guarantees of these specifications.
>
> In particular, for the complex variable z=(x,y), CABS() may be
> computed via sqrt(x*x+y*y), which is subject to overflow and
> underflow (i.e., x = 1e20, y = 1e-20 for REAL(4)). The likelihood
> of these problems occurring can be can be significantly reduced
> by using the algorithm behind hypot(3), which the library implementation
> of CABS may do.
-fno-cx-limited-range should over-rule the narrow range setting of cabs().
OP appeared to want to know how to generate in-line code for cabs(),
apparently (not unreasonably) confusing the Fortran term INTRINSIC with
in-lining (or gcc builtin).
Compilers which set options like -ffast-math as default will protect
against "limited-range," possibly by automatically switching cabs() to 387
code. Generally, such compilers require some option to be set to gain
reasonable compliance with Fortran standard. It is clear that the
defaults of gfortran are more satisfactory in contexts other than winning
benchmarks which allow only 2 command line options to be set.