[Bug fortran/57628] New: spurious error: division by zero in if statement

[Bug fortran/57628] New: spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

            Bug ID: 57628
           Summary: spurious error: division by zero in if statement
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: furue at hawaii dot edu

Dear gfortran maintainers,

Division by zero causes error even when it's not executed:

program try
  implicit NONE
  real, parameter:: a = 0.0
  if (a > 0) then
    write(*,*) 1/a
  end if
end program try

$ /usr/bin/gfortran tmp.f90
tmp.f90:5.16:

    write(*,*) 1/a
                1
Error: Division by zero at (1)
$

If it's difficult to give a correct diagnosis, please demote this to a warning.

I have a lot of constructs like this because I change the parameter often and
so this behavior of gfortran is very inconvenient (because I have to rewrite my
source code to be able to compile it).

Regards,
Ryo

[Bug fortran/57628] spurious error: division by zero in if statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |kargl at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Ryo Furue from comment #0)
> Dear gfortran maintainers,
> 
> Division by zero causes error even when it's not executed:

But, it is evaluated at compile time, and so, you'll
get the error.

> 
> If it's difficult to give a correct diagnosis, please demote this to a
> warning.

You are getting the correct diagnosis!

[Bug fortran/57628] spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

--- Comment #2 from Ryo Furue <furue at hawaii dot edu> ---
Thank you for the prompt response!

> But, it is evaluated at compile time, and so, you'll
> get the error.

I understand that.

> You are getting the correct diagnosis!

Of course.  I agree with all your statements.

And your entirely entirely miss the point!

This is a "quality of implementation" issue.  

Since my code includes an expression that can be evaluated at compile time and
it's a division by zero, the compiler has the right to treat it as error.
(But, that's my guess.  What does the standard say?  The standard doesn't have
the notion of "compile time", so I wonder how such a case as this is treated in
the standard.)

The question is "Is refusing to compile it the best way to deal with this
error?"  My answer is no.  Since,

  real, parameter:: a = 0
  If (a > 0) then
    write(*,*) 1/a !! this part
  end if

the contents of the IF statement is unreachable, the compiler more
appropriately would issue an "unreachable statements" warning and disregard the
contents of the unreachable code.  In my opinion.

Cheers,
Ryo

[Bug fortran/57628] spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

--- Comment #3 from Ryo Furue <furue at hawaii dot edu> ---
(In reply to kargl from comment #1)
Thank you for the prompt response!

[This is a re-post. I missed the "reply" feature and made a typo.  I would
delete the other post, if possible.]

> But, it is evaluated at compile time, and so, you'll
> get the error.

I understand that.

> You are getting the correct diagnosis!

Of course.  I agree with all your statements.

And your statements entirely miss the point!

This is a "quality of implementation" issue.  

Since my code includes an expression that can be evaluated at compile time and
it's a division by zero, the compiler has the right to treat it as error.
(But, that's my guess.  What does the standard say?  The standard doesn't have
the notion of "compile time", so I wonder how such a case as this is treated in
the standard.)

The question is "Is refusing to compile it the best way to deal with this
error?"  My answer is no.  Since,

  real, parameter:: a = 0
  If (a > 0) then
    write(*,*) 1/a !! this part
  end if

the contents of the IF statement is unreachable, the compiler more
appropriately would issue an "unreachable statements" warning and disregard the
contents of the unreachable code.  In my opinion.

Cheers,
Ryo

[Bug fortran/57628] spurious error: division by zero in if statement

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>Since my code includes an expression that can be evaluated at compile time and it's a division by zero,

parameter are special in fortran.  The expression is evaluated at compile time
because of the parameter.  a has to be replaced with 0 according to the fortran
standard which is why you are getting this error.

[Bug fortran/57628] spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

--- Comment #5 from Ryo Furue <furue at hawaii dot edu> ---
(In reply to Andrew Pinski from comment #4)
> parameter are special in fortran.  The expression is evaluated at compile
> time because of the parameter.  a has to be replaced with 0 according to the
> fortran standard which is why you are getting this error.

I understand that!  And I've realized my mistake in saying "spurious" in the
title of my submission.  I apologize.  But, my main point stands.

There should be a compiler option (or something) that lets the code like my go.
 You could replace the expression "1.0/0.0" with an IEEE "Inf" and let the code
go, couldn't you?

As a quality of implementation issue, the current behavior of gfortran isn't
ideal.

Having said that, are you sure the standard states

1) that a parameter must be substituted
  at compile time? The standard doesn't have the notion
  of compile time.

2) that this code should be rejected by the compiler?

I'm pretty sure that the standard doesn't say (2).  The compiler states what is
legal code and what is illegal.  But it doesn't say what to do with an illegal
code.

Cheers,
Ryo

[Bug fortran/57628] spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

--- Comment #6 from Ryo Furue <furue at hawaii dot edu> ---
(In reply to Ryo Furue from comment #5)

I'm correcting two typos.  Sorry.

> (In reply to Andrew Pinski from comment #4)
> > parameter are special in fortran.  The expression is evaluated at compile
> > time because of the parameter.  a has to be replaced with 0 according to the
> > fortran standard which is why you are getting this error.
> 
> I understand that!  And I've realized my mistake in saying "spurious" in the
> title of my submission.  I apologize.  But, my main point stands.
> 
> There should be a compiler option (or something) that lets the code like my

lets the code like "mine" go.

> go.  You could replace the expression "1.0/0.0" with an IEEE "Inf" and let
> the code go, couldn't you?
> 
> As a quality of implementation issue, the current behavior of gfortran isn't
> ideal.
> 
> Having said that, are you sure the standard states
> 
> 1) that a parameter must be substituted
>   at compile time? The standard doesn't have the notion
>   of compile time.
> 
> 2) that this code should be rejected by the compiler?
> 
> I'm pretty sure that the standard doesn't say (2).  The compiler states what

The "standard" states what is legal . . .

> is legal code and what is illegal.  But it doesn't say what to do with an
> illegal code.
> 
> Cheers,
> Ryo

[Bug fortran/57628] spurious error: division by zero in if statement

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
AFAICT the option -fno-range-check is what you are looking for.

[Bug fortran/57628] spurious error: division by zero in if statement

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Jun 16, 2013 at 07:57:23AM +0000, furue at hawaii dot edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
> 
> --- Comment #2 from Ryo Furue <furue at hawaii dot edu> ---
> 
> Of course.  I agree with all your statements.
> 
> And your entirely entirely miss the point!
> 

No, I did not miss your point.

> This is a "quality of implementation" issue.  

So, the compiler should just arbitrarily chose to evaluate
some expression and ignore others?

> The question is "Is refusing to compile it the best way to deal with this
> error?"  My answer is no.  Since,
> 
>   real, parameter:: a = 0
>   If (a > 0) then

So, the compiler should evaluate "a > 0", but it should

>     write(*,*) 1/a !! this part

not evaluate "1/a".

>   end if
> 
> the contents of the IF statement is unreachable, the compiler more
> appropriately would issue an "unreachable statements" warning
> and disregard the contents of the unreachable code.

DCE will take care of unreachable code in the middle-end.

Just remove the PARAMETER attribute in your code, it it will
do what you.

real :: a = 0
if (a > 0) then
   print *, 1/a
else
   print *, 'doh!'
end if
end

[Bug fortran/57628] spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

--- Comment #9 from Ryo Furue <furue at hawaii dot edu> ---
(In reply to Steve Kargl from comment #8)

> So, the compiler should just arbitrarily chose to evaluate
> some expression and ignore others?

No, I don't mean that.  I'm not saying which expression the compiler should
evaluate.  What I'm saying is, what is the best way to deal with the result of
the evaluation?

The compiler "can" (or "should"?) evaluate 1/a at compile time if a is a
parameter.  But, it's "useful" to provide an option that allows the compiler to
let the code pass even if a == 0 (with a warning message, perhaps).  That's
what I argue.

I don't think the compiler "must" evaluate "1/a" or "a>0" at compile time. 
It's at the compiler's discretion.  But, whatever it does "should" be maximally
"useful" (as long as the chosen behavior does not violate the Fortran
standard).

> Just remove the PARAMETER attribute in your code, it it will
> do what you.
> 
> real :: a = 0
> if (a > 0) then
>    print *, 1/a
[. . .]

Yes, I was about to come to that!  I write my code that way because I plan to
provide the value of "a" from an external module in the future.  Currently I
set the value with PARAMETER just as a convenience during the development of
the code.  So, you are right, that your solution is one workaround for my
situation.

But, I feel strongly uneasy looking at the code because "real::a = 0" is a
strong indication that the value of "a" will be altered after the definition. 
The codes we are showing in this message exchange are shortened versions and in
my real codes, there are some lines between "real, parameter:: a = 0" and the
IF statement.  When I see "real:: a = 0.0", I expect the value of "a" will be
altered because I don't see PARAMETER.

Also, I still don't like this (sort of) "inconsistency".  It's more natural to
expect the outcome of the code be the same whether it's "real, parameter:: a =
0" or "real:: a = 0".  Another example is,

  real, parameter:: a = -1.0
  if (a > 0) write(*,*) sqrt(a)

This does not compile.  If we replace sqrt with yoursqrt, it compiles. (I know
the reason why gfortran does this.  That's not my question.)

Overall, I think this kind of thing is better be a "warning" and that at least
the compiler should allow the user to run such a code as this.  The result of
the run may be a disaster but it's the user's responsibility.  To refuse to
compile these codes is too much patronizing on the part of the compiler.

Cheers,
Ryo

P.S. How does this interact with the IEEE support of F2003?  I may be wrong,
but I thought that replacing 1.0/0.0 with "Inf" at compile time would be a
useful extension (without violating the Fortran standard, of course).  Again,
I'm not saying the compiler must do this.  All I'm saying is that it may be
useful.

[Bug fortran/57628] spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

--- Comment #10 from Ryo Furue <furue at hawaii dot edu> ---
(In reply to Dominique d'Humieres from comment #7)
> AFAICT the option -fno-range-check is what you are looking for.

Thanks!  That's exactly it.

But, I'm curious.  The following code still fails to compile even with
-fno-range-check :

program try
  real, parameter:: a = -1.0
  if (a > 0) then
    write(*,*) sqrt(a)
  end if
end program try

$ gfortran -fno-range-check tmp.f90
tmp.f90:4.20:

    write(*,*) sqrt(a)
                    1
Error: Argument of SQRT at (1) has a negative value
$

Is this an inconsistency in the implementation of -no-range-check ?

I would be nice if there were an option to demote this type of error to a
warning.

Cheers,
Ryo

[Bug fortran/57628] spurious error: division by zero in if statement

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Jun 16, 2013 at 11:28:36PM +0000, furue at hawaii dot edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
> 
> --- Comment #9 from Ryo Furue <furue at hawaii dot edu> ---
> (In reply to Steve Kargl from comment #8)
> 
> > So, the compiler should just arbitrarily chose to evaluate
> > some expression and ignore others?
> 
> No, I don't mean that.  I'm not saying which expression the compiler should
> evaluate.  What I'm saying is, what is the best way to deal with the result of
> the evaluation?

I think you found the answer.  gfortran issues an error, so
a user has the chance to fix her code.

> 
> > Just remove the PARAMETER attribute in your code, it it will
> > do what you.
> > 
> > real :: a = 0
> > if (a > 0) then
> >    print *, 1/a
> [. . .]
> 
> Yes, I was about to come to that!  I write my code that way because I plan to
> provide the value of "a" from an external module in the future.  Currently I
> set the value with PARAMETER just as a convenience during the development of
> the code.  So, you are right, that your solution is one workaround for my
> situation.
> 
> But, I feel strongly uneasy looking at the code because "real::a = 0" is a
> strong indication that the value of "a" will be altered after the definition. 

Fortunately, Fortran allows more than a single character in a variable
name (and comments). 
  !
  ! This a flag set by the programmer prior to compilation.
  ! <Description of what the flag does goes here>
   real :: immutable_flag = 0

> The codes we are showing in this message exchange are shortened versions and in
> my real codes, there are some lines between "real, parameter:: a = 0" and the
> IF statement.  When I see "real:: a = 0.0", I expect the value of "a" will be
> altered because I don't see PARAMETER.

Not if the code is properly commented and the variable is suitably
named.

> Overall, I think this kind of thing is better be a "warning" and that at least
> the compiler should allow the user to run such a code as this.  The result of
> the run may be a disaster but it's the user's responsibility.  To refuse to
> compile these codes is too much patronizing on the part of the compiler.

I think that it is better to issue an error.

> but I thought that replacing 1.0/0.0 with "Inf" at compile time would be a
> useful extension (without violating the Fortran standard, of course).  Again,
> I'm not saying the compiler must do this.  All I'm saying is that it may be
> useful.

gfortran does not support the IEEE 2003 standard.  No one has stepped
up to the plate.  Here's your chance to make gfortran doe whatever
you think the standard mandates.

[Bug fortran/57628] spurious error: division by zero in if statement

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Jun 16, 2013 at 11:33:49PM +0000, furue at hawaii dot edu wrote:
> 
> Is this an inconsistency in the implementation of -no-range-check ?

No.

> 
> I would be nice if there were an option to demote this type of error to a
> warning.
> 

Not going to happen.

[Bug fortran/57628] spurious error: division by zero in if statement

[anlauf at gmx dot de]

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

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #13 from Harald Anlauf <anlauf at gmx dot de> ---
Hi Ryo!

(In reply to Ryo Furue from comment #10)
> (In reply to Dominique d'Humieres from comment #7)
> > AFAICT the option -fno-range-check is what you are looking for.
> 
> Thanks!  That's exactly it.
> 
> But, I'm curious.  The following code still fails to compile even with
> -fno-range-check :
> 
> program try
>   real, parameter:: a = -1.0
>   if (a > 0) then
>     write(*,*) sqrt(a)
>   end if
> end program try
> 
> $ gfortran -fno-range-check tmp.f90
> tmp.f90:4.20:
> 
>     write(*,*) sqrt(a)
>                     1
> Error: Argument of SQRT at (1) has a negative value
> $
> 
> Is this an inconsistency in the implementation of -no-range-check ?
> 
> I would be nice if there were an option to demote this type of error to a
> warning.

I would also prefer if gfortran behaved as you suggested.
Other compilers appear to generate warnings only, or no comment.
After all, the code path in question never gets executed.

I am afraid that the Fortran standard document does not give
much help here and may allow gfortran's behavior.  Nevertheless
I recommend to ask in comp.lang.fortran where you'll probably
get a better explanation.

> Cheers,
> Ryo

[Bug fortran/57628] spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

--- Comment #14 from Ryo Furue <furue at hawaii dot edu> ---
(In reply to Steve Kargl from comment #11)

> > Overall, I think this kind of thing is better be a "warning" and that at least
> > the compiler should allow the user to run such a code as this.  The result of
> > the run may be a disaster but it's the user's responsibility.  To refuse to
> > compile these codes is too much patronizing on the part of the compiler.
> 
> I think that it is better to issue an error.

The fact that you think so doesn't prevent you from giving gfortran an option
to demote it to a warning, does it? because that would please both camps. 
Other users (at least two of us) think a warning is better.  And I gave an
example where a warning is better suited to the purpose at hand.

> gfortran does not support the IEEE 2003 standard.  No one has stepped
> up to the plate.  Here's your chance to make gfortran doe whatever
> you think the standard mandates.

I'm not saying gfortran should implement the IEEE 2003 standard.  I was just
wondering whether the extension of replacing 1.0/0.0 with Inf now
(-fno-range-check does that) would become more in harmony with the IEEE 2003
standard when gfortran implements it in the future.  If so, replacing 1.0/0.0
with Inf as a default behavior (with a warming message) may be a better choice
now.  I was just wondering.  I may be wrong.  That may be a bad extension now.

Cheers,
Ryo

[Bug fortran/57628] spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

--- Comment #15 from Ryo Furue <furue at hawaii dot edu> ---
(In reply to Harald Anlauf from comment #13)

Hi Harald,

Thanks for your message.

> I would also prefer if gfortran behaved as you suggested.
> Other compilers appear to generate warnings only, or no comment.
> After all, the code path in question never gets executed.
> 
> I am afraid that the Fortran standard document does not give
> much help here and may allow gfortran's behavior. 

I'm pretty sure that the Fortran standard allows gfortran's behavior.  I'm not
arguing that it's a violation of the standard.  I'm just asking for an option
to change the behavior (which would also within the standard).

The question is what is the best way to deal with illegal bits of code.  There,
there are a number of choices all within the standard.  For example, with this

  program try
    real:: a(10) = 1.0/0.0
    write(10) a
  end program try

the compiler is allowed to do anything and there is no single answer as to
what's best.  In some circumstances, to stop compiling with an error message is
the best way (gfortran's default behavior); in some circumstances, to replace
the constant expression with the IEEE +Infinity value and let the code pass
(-fno-range-check) is a better choice.  I certainly would write such a code as
the above to get a binary array of Infinities. (It's a quick-n-dirty way but it
works in practice.)

In other circumstances, the compiler can send en email message to the writer of
such a code, pointing out the stupidity of it :-)

Cheers,
Ryo

[Bug fortran/57628] spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

--- Comment #18 from Ryo Furue <furue at hawaii dot edu> ---
(In reply to Steve Kargl from comment #17)

> >   real, parameter:: a = -1.0
> >   if (a > 0) write(*,*) sqrt(a)
> > 
> > With such a switch turned on, the compiler can replace sqrt(-1.0) with NaN and
> > let the code pass.
> > 
> 
> Why not replace it with 0 instead of NaN?

I think that would be another good choice.  I'm not insisting on NaN at all. 
sqrt(-1.0) is undefined within real numbers, so NaN is one valid choice.  But,
as you say, it's defined in complex numbers, so converting it to zero is
another valid choice.  A third valid choice is to convert it to complex number
(0.0,-1.0).  I'm not saying which is the most valid.  I just think NaN is the
most sensible choice NOW, if we disregard the history of the Fortran language.
(I guess the IEEE standard says that NaN is the result, but I'm not sure at
all.)

> Yeah, I get it.  You don't like the choice that gfortran
> made 10+ years ago.

Not quite.  Whether I like it or not doesn't matter.  All I'm saying is that
adding an option to convert those "invalid" numbers according to the IEEE rule
(or in the absence of the IEEE rule for particular conversions, to some
sensible numbers) and let the code pass would be a useful extension to gfortran
NOW.  Since it's a useful extension with little harm, that is a good addition
to gfortran to enhance its usefulness, I think.

Before signing off, I'd like to apologize for my submitting this as a "bug". 
Through this conversation, I quickly realized I was wrong in thinking it is a
bug.  I should have submitted it as a "wish", so that some of the developers
might consider it as a future extension.

Cheers,
Ryo

[Bug fortran/57628] spurious error: division by zero in if statement

[furue at hawaii dot edu]

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

--- Comment #19 from Ryo Furue <furue at hawaii dot edu> ---
(In reply to Ryo Furue from comment #18)

Sorry again.  I made English error.

> > Yeah, I get it.  You don't like the choice that gfortran
> > made 10+ years ago.
> 
> Not quite. 

I meant, You are not quite right in thinking that I don't like your choice.

English is my second language and the use of "not" occasionally trips me up.

Cheers,
Ryo