From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17879 invoked by alias); 17 Jun 2013 21:25:39 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17821 invoked by uid 48); 17 Jun 2013 21:25:34 -0000 From: "furue at hawaii dot edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/57628] spurious error: division by zero in if statement Date: Mon, 17 Jun 2013 21:25:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.7.3 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: furue at hawaii dot edu X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg00932.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #14 from Ryo Furue --- (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