public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "furue at hawaii dot edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/57628] spurious error: division by zero in if statement
Date: Sun, 16 Jun 2013 23:28:00 -0000	[thread overview]
Message-ID: <bug-57628-4-moJMIMLIqI@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-57628-4@http.gcc.gnu.org/bugzilla/>

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.


  parent reply	other threads:[~2013-06-16 23:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-16  6:39 [Bug fortran/57628] New: " furue at hawaii dot edu
2013-06-16  7:22 ` [Bug fortran/57628] " kargl at gcc dot gnu.org
2013-06-16  7:57 ` furue at hawaii dot edu
2013-06-16  8:13 ` furue at hawaii dot edu
2013-06-16  8:26 ` pinskia at gcc dot gnu.org
2013-06-16  8:47 ` furue at hawaii dot edu
2013-06-16  8:50 ` furue at hawaii dot edu
2013-06-16 14:34 ` dominiq at lps dot ens.fr
2013-06-16 14:55 ` sgk at troutmask dot apl.washington.edu
2013-06-16 23:28 ` furue at hawaii dot edu [this message]
2013-06-16 23:33 ` furue at hawaii dot edu
2013-06-17  5:00 ` sgk at troutmask dot apl.washington.edu
2013-06-17  5:00 ` sgk at troutmask dot apl.washington.edu
2013-06-17 18:54 ` anlauf at gmx dot de
2013-06-17 21:25 ` furue at hawaii dot edu
2013-06-17 21:42 ` furue at hawaii dot edu
2013-06-18  1:47 ` furue at hawaii dot edu
2013-06-18  1:56 ` furue at hawaii dot edu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-57628-4-moJMIMLIqI@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).