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) = [(latt100(i
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&action=edit
tar including all the sourc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #19 from Ryo Furue ---
(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 rig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #18 from Ryo Furue ---
(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
> > le
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #16 from Ryo Furue ---
(In reply to Steve Kargl from comment #12)
> 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 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #15 from Ryo Furue ---
(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.
>
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #10 from Ryo Furue ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #9 from Ryo Furue ---
(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 sh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #6 from Ryo Furue ---
(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 beca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #5 from Ryo Furue ---
(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 stan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #3 from Ryo Furue ---
(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 co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #2 from Ryo Furue ---
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 statemen
: 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
en
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56555
Ryo Furue changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56555
--- Comment #1 from Ryo Furue 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
Bug #: 56555
Summary: read from pipe
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
--- 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 "<".
--- 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 #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 form
ces wrong output
Product: gcc
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
21 matches
Mail list logo
