[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
sgk at troutmask dot apl dot washington dot edu
gcc-bugzilla@gcc.gnu.org
Tue Jan 13 19:55:00 GMT 2009
------- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2009-01-13 19:55 -------
Subject: Re: Diagnose and treat (-2.0)**2.0 properly
On Tue, Jan 13, 2009 at 11:30:40AM -0000, dominiq at lps dot ens dot fr wrote:
>
>
> ------- Comment #2 from dominiq at lps dot ens dot fr 2009-01-13 11:30 -------
> > The question is whether one needs to reject it completely or only with -std=f95.
>
> I vote for "only with -std=f95" with may be a warning otherwise.
It will be a compile time error during constant folding. The compiler
can detect (-2.)**some_real_entity.
> I think it is a legitimate optimization to replace A**B by A**I (with I=B)
> when B is known to be an integer, hence to accept negative values for A
> in this case.
I have no plans to change this optimization.
> I find upsetting to have to cheat with variables when constant folding
> does not give the same result as a similar code with variables.
In the general case,
function my_pow(x,y)
real my_pow
real x, y
my_pow = x**y
end function my_pow
we have
my_pow (real(kind=4) & x, real(kind=4) & y)
{
real(kind=4) __result_my_pow;
{
real(kind=4) D.1525;
D.1525 = *x;
__result_my_pow = __builtin_powf (D.1525, *y);
}
return __result_my_pow;
}
I intend to change this, conditional on perhaps -ffast-math and/or -pedantic,
to
D.1525 = *x;
if (D.1525 < 0)
runtime_error( )
else
__result_my_pow = __builtin_powf (D.1525, *y);
gfortran's default behavior in this instance should be conformance to
the Standards.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
More information about the Gcc-bugs
mailing list