[Bug fortran/38823] New: Diagnose and treat (-2.0)**2.0 properly

[Bug fortran/38823] New: Diagnose and treat (-2.0)**2.0 properly

[burnus at gcc dot gnu dot org]

Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2

  print *, (-2.0)**2.0
  end
is invalid. gfortran should print a diagnostic for -std=f95/f2003/f2008 as NAG
f95 does:
  Error: Negative floating-point value raised to a real power

Fortran 2003 in the second sentence of the second paragraph of "7.1.8
Evaluation of Operations":

  "Raising a negative-valued primary of type real to a real power is
   prohibitted."

The question is whether one needs to reject it completely or only with
-std=f95. Steve (see thread) thinks the constant folding gets it wrong
(-> gives "4.0").

Current results:
- Runtime and compile time evaluation (ifort, gfortran, g95):
  -2.0**2.0 = 4.0
  -2.0**1.9 = NaN
- Mathematica:
  -2^2 = 4, -2.0^2.0 = -4.0
  2.0^1.9 = -3.73213


-- 
           Summary: Diagnose and treat (-2.0)**2.0 properly
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

Re: [Bug fortran/38823] New: Diagnose and treat (-2.0)**2.0 properly

[Andrew Thomas Pinski]

On Jan 13, 2009, at 3:08 AM, "burnus at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

> Found at:
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2
>
>  print *, (-2.0)**2.0
>  end
> is invalid. gfortran should print a diagnostic for -std=f95/f2003/ 
> f2008 as NAG
> f95 does:
>  Error: Negative floating-point value raised to a real power
>
> Fortran 2003 in the second sentence of the second paragraph of "7.1.8
> Evaluation of Operations":
>
>  "Raising a negative-valued primary of type real to a real power is
>   prohibitted."
>
> The question is whether one needs to reject it completely or only with
> -std=f95. Steve (see thread) thinks the constant folding gets it wrong
> (-> gives "4.0").
>
> Current results:
> - Runtime and compile time evaluation (ifort, gfortran, g95):
>  -2.0**2.0 = 4.0
>  -2.0**1.9 = NaN
> - Mathematica:
>  -2^2 = 4, -2.0^2.0 = -4.0
>  2.0^1.9 = -3.73213

-2.0^1.9 will be a complex number.  Maybe we can define it as taking  
the real part. I don't know if that is better than generating a nan  
here.

Thanks,
Andrew Pinski


>
>
>
> -- 
>           Summary: Diagnose and treat (-2.0)**2.0 properly
>           Product: gcc
>           Version: 4.4.0
>            Status: UNCONFIRMED
>          Keywords: diagnostic
>          Severity: normal
>          Priority: P3
>         Component: fortran
>        AssignedTo: unassigned at gcc dot gnu dot org
>        ReportedBy: burnus at gcc dot gnu dot org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
>

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[pinskia at gmail dot com]

------- Comment #1 from pinskia at gmail dot com  2009-01-13 11:28 -------
Subject: Re:   New: Diagnose and treat (-2.0)**2.0 properly

On Jan 13, 2009, at 3:08 AM, "burnus at gcc dot gnu dot org"
<gcc-bugzilla@gcc.gnu.org 
 > wrote:

> Found at:
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2
>
>  print *, (-2.0)**2.0
>  end
> is invalid. gfortran should print a diagnostic for -std=f95/f2003/ 
> f2008 as NAG
> f95 does:
>  Error: Negative floating-point value raised to a real power
>
> Fortran 2003 in the second sentence of the second paragraph of "7.1.8
> Evaluation of Operations":
>
>  "Raising a negative-valued primary of type real to a real power is
>   prohibitted."
>
> The question is whether one needs to reject it completely or only with
> -std=f95. Steve (see thread) thinks the constant folding gets it wrong
> (-> gives "4.0").
>
> Current results:
> - Runtime and compile time evaluation (ifort, gfortran, g95):
>  -2.0**2.0 = 4.0
>  -2.0**1.9 = NaN
> - Mathematica:
>  -2^2 = 4, -2.0^2.0 = -4.0
>  2.0^1.9 = -3.73213

-2.0^1.9 will be a complex number.  Maybe we can define it as taking  
the real part. I don't know if that is better than generating a nan  
here.

Thanks,
Andrew Pinski


>
>
>
> -- 
>           Summary: Diagnose and treat (-2.0)**2.0 properly
>           Product: gcc
>           Version: 4.4.0
>            Status: UNCONFIRMED
>          Keywords: diagnostic
>          Severity: normal
>          Priority: P3
>         Component: fortran
>        AssignedTo: unassigned at gcc dot gnu dot org
>        ReportedBy: burnus at gcc dot gnu dot org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[dominiq at lps dot ens dot fr]

------- 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. 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 find
upsetting to have to cheat with variables when constant folding does not give
the same result as a similar code with variables.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[dominiq at lps dot ens dot fr]

------- Comment #3 from dominiq at lps dot ens dot fr  2009-01-13 11:37 -------
> - Mathematica:
>   -2^2 = 4, -2.0^2.0 = -4.0
>   2.0^1.9 = -3.73213      <------- probably -2.0^1.9!

Apparently Mathematica parse "-2.0^a" as "-(2.0^a)". (-2.0)^1.9 gives "3.54947-
1.15329 I". I don't know if the fortran standard says how "-a**b" should be
parsed (nor have the time right now to decipher the legalese).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2009-01-13 16:35 -------
I wonder whether this should be fixed together with PR 38823.
Currently, (x)**(non-integer) is never be simplified at compile time - and the
simplification would be an obvious place to do the checking.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #5 from sgk at troutmask dot apl dot washington dot edu  2009-01-13 19:43 -------
Subject: Re:   New: Diagnose and treat (-2.0)**2.0 properly

On Tue, Jan 13, 2009 at 11:08:40AM -0000, burnus at gcc dot gnu dot org wrote:
> 
> Fortran 2003 in the second sentence of the second paragraph of "7.1.8
> Evaluation of Operations":
> 
>   "Raising a negative-valued primary of type real to a real power is
>    prohibitted."
> 
> The question is whether one needs to reject it completely or only with
> -std=f95. Steve (see thread) thinks the constant folding gets it wrong
> (-> gives "4.0").

For constant folding, it will be rejected because it can be detected
at compile time.

> Current results:
> - Runtime and compile time evaluation (ifort, gfortran, g95):
>   -2.0**2.0 = 4.0
>   -2.0**1.9 = NaN

I believe you're missing ( ) around -2.0 because ** has higher
precedence than unary minus.

> - Mathematica:
>   -2^2 = 4, -2.0^2.0 = -4.0
>   2.0^1.9 = -3.73213

Try putting ( ) around -2 in the above.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #6 from sgk at troutmask dot apl dot washington dot edu  2009-01-13 19:44 -------
Subject: Re:  Diagnose and treat (-2.0)**2.0 properly

On Tue, Jan 13, 2009 at 11:28:05AM -0000, pinskia at gmail dot com wrote:
> 
> -2.0^1.9 will be a complex number.  Maybe we can define it as taking  
> the real part. I don't know if that is better than generating a nan  
> here.
> 

The ** operator has higher precedence than unary minus.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[sgk at troutmask dot apl dot washington dot edu]

------- 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

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #8 from sgk at troutmask dot apl dot washington dot edu  2009-01-13 19:58 -------
Subject: Re:  Diagnose and treat (-2.0)**2.0 properly

On Tue, Jan 13, 2009 at 11:37:25AM -0000, dominiq at lps dot ens dot fr wrote:
> 
> 
> ------- Comment #3 from dominiq at lps dot ens dot fr  2009-01-13 11:37 -------
> > - Mathematica:
> >   -2^2 = 4, -2.0^2.0 = -4.0
> >   2.0^1.9 = -3.73213      <------- probably -2.0^1.9!
> 
> Apparently Mathematica parse "-2.0^a" as "-(2.0^a)". (-2.0)^1.9 gives "3.54947-
> 1.15329 I". I don't know if the fortran standard says how "-a**b" should be
> parsed (nor have the time right now to decipher the legalese).
> 

See Note 7.30 in the Fortran 2003 Standard.

-a**b is parsed as if it were written as -(a**b).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[mikael at gcc dot gnu dot org]

------- Comment #9 from mikael at gcc dot gnu dot org  2009-01-13 20:08 -------
(In reply to comment #2)
> 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. 
You can use A**I directly if you want to accept negative values.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[dominiq at lps dot ens dot fr]

------- Comment #10 from dominiq at lps dot ens dot fr  2009-01-13 21:13 -------
> I intend to change this, conditional on perhaps -ffast-math and/or -pedantic,

I don't understand the "and/or": -ffast-math and -pedantic at the same time
does not make any sense for me, -ffast-math allows some sloppiness with respect
to the standard, while -pedantic does not.

> You can use A**I directly if you want to accept negative values.

I have never said that (-2.0)**2.0 is in my coding style. My point is that a
pedantic implementation triggers too many bug reports and are not worth the
time spent on it (see -2**31).

I agree with comment#0 "gfortran should print a diagnostic for
-std=f95/f2003/f2008", but not without -std=*.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #11 from sgk at troutmask dot apl dot washington dot edu  2009-01-13 21:30 -------
Subject: Re:  Diagnose and treat (-2.0)**2.0 properly

On Tue, Jan 13, 2009 at 09:13:57PM -0000, dominiq at lps dot ens dot fr wrote:
> 
> 
> ------- Comment #10 from dominiq at lps dot ens dot fr  2009-01-13 21:13 -------
> > I intend to change this, conditional on perhaps -ffast-math and/or -pedantic,
> 
> I don't understand the "and/or": -ffast-math and -pedantic at the same time
> does not make any sense for me, -ffast-math allows some sloppiness with respect
> to the standard, while -pedantic does not.

I haven't decided how I want to handle the general case.  There
are few possibilities:

gfortran file.f90
  Do nothing, ie., the status quo

gfortran -pedantic file.f90 
  Add a runtime check that x in x**y is not < 0.

or

gfortran file.f90
  Add a runtime check that x in x**y is not < 0.

gfortran -ffast-math file.f90 
  Do not add a runtime check.

or 

gfortran -fsome_new_option file.f90
  Add a runtime check.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[burnus at gcc dot gnu dot org]

------- Comment #12 from burnus at gcc dot gnu dot org  2009-01-13 21:41 -------
>  Add a runtime check that x in x**y is not < 0

I'm actually against a run time check which is based on -std=, -pedantic, -W*
or similar compile time diagnostic flags. I regard such trickery behind the
scenes as evil and I would expect such an error only for -fcheck*

Note, there is already a check for
  x = -1.9
  y = (-2.0)**(x)
It gives NaN - and with trapping that is a SIGFPE. I think that should good
enough, but I don't mind having a -fcheck* option adding a run-time check.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[kargl at gcc dot gnu dot org]

------- Comment #13 from kargl at gcc dot gnu dot org  2009-01-16 00:40 -------
I have a patch for this problem.  I'll clean it up on Saturday and
submit it.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |kargl at gcc dot gnu dot org
                   |dot org                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[jb at gcc dot gnu dot org]

-- 

jb at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-18 00:25:57
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[kargl at gcc dot gnu dot org]

------- Comment #14 from kargl at gcc dot gnu dot org  2009-01-19 00:36 -------
http://gcc.gnu.org/ml/fortran/2009-01/msg00231.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[kargl at gcc dot gnu dot org]

------- Comment #15 from kargl at gcc dot gnu dot org  2009-03-29 20:33 -------
Subject: Bug 38823

Author: kargl
Date: Sun Mar 29 20:33:07 2009
New Revision: 145261

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145261
Log:
2009-03-29  Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/38823
        * gfortran.dg/power1.f90: New test.

2009-03-29  Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/38823
        * gfortran.h: Add ARITH_PROHIBIT to arith enum.
        expr.c (gfc_match_init_expr): Add global variable init_flag to
        flag matching an initialization expression.
        (check_intrinsic_op): Move no longer reachable error message to ...
        * arith.c (arith_power): ... here.  Remove gfc_ prefix in
        gfc_arith_power.  Use init_flag.  Allow constant folding of x**y
        when y is REAL or COMPLEX.
        (eval_intrinsic): Remove restriction that y in x**y must be INTEGER
        for constant folding.
        * gfc_power: Update gfc_arith_power to arith_power


Added:
    trunk/gcc/testsuite/gfortran.dg/power1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/arith.c
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[kargl at gcc dot gnu dot org]

------- Comment #16 from kargl at gcc dot gnu dot org  2009-03-29 20:37 -------
Fixed on trunk.  There are no plans to fix this in 4.4.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823

[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly

[kargl at gcc dot gnu dot org]

-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823