https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99506
--- Comment #3 from Ryo Furue ---
After posting the initial report, I tried my code with another compiler and
found a few bugs in there. In the most reduced code, one of them is still
there:
> real(double), parameter:: latt(jmax) =
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: furue at hawaii dot edu
Target Milestone: ---
Created attachment 50346
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50346=edit
tar including all the source fi
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #16 from Ryo Furue furue at hawaii dot edu ---
(In reply to Steve Kargl from comment #12)
On Sun, Jun 16, 2013 at 11:33:49PM +, furue at hawaii dot edu wrote:
Is this an inconsistency in the implementation of -no-range-check
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
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
: 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
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
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
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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56555
Bug #: 56555
Summary: read from pipe
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56555
--- Comment #1 from Ryo Furue furue at hawaii dot edu 2013-03-07 00:33:40 UTC
---
I'm sorry That was a mistake! I want to withdraw it but don't know how.
I'm very sorry for posting a total nonsense!
Ryo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56555
Ryo Furue furue at hawaii dot edu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: furue at hawaii dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35036
--- Comment #3 from furue at hawaii dot edu 2008-01-31 02:00 ---
Subject: Re: illegal E format descriptor produces wrong
output
Hi,
| --- Comment #2 from kargl at gcc dot gnu dot org 2008-01-31 01:46
---
| (In reply to comment #0)
| E8.0 is an illegal format descriptor
--- Comment #5 from furue at hawaii dot edu 2008-01-31 02:45 ---
Subject: Re: illegal E format descriptor produces wrong
output
| There is no restriction in F95 that d must be positive in Ew.d.
| In 10.6.5.1, it clearly states that k = 0 at the beginning of
| execution of an input
--- Comment #8 from furue at hawaii dot edu 2008-01-31 06:16 ---
Subject: Re: illegal E format descriptor produces wrong
output
| I may be missing something, but -d k = 0 doesn't hold
| when d = 0 and k = 0. Notice the inequality . So, when k = 0,
| how should we read the part
21 matches
Mail list logo
