[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