[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
-- 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
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
--- 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
--- 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 PR fortran/38823 * gfortran.dg/power1.f90: New test. 2009-03-29 Steven G. Kargl 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
--- 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
-- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-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
--- 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
--- 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
--- 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 -, 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
--- 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
--- 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
--- 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 -, 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
--- 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 -, 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
--- 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 -, 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
--- 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 -, 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
--- 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
--- 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
--- 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
--- 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" 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
