[Bug fortran/35036] New: illegal E format descriptor produces wrong output
"E8.0" is an illegal format descriptor, but g77 produces a wrong output
"0.1+01" for a value of 1e5, instead of a more sensible "" .
$ cat tmp.f
a = 1.e5
write(*,'(E8.0)') a
end
$ g77 --version
GNU Fortran (GCC) 3.4.6 (Debian 3.4.6-6)
[. . .]
$ g77 tmp.f
$ ./a.out
0.1+01
$
OK, since the format descriptor is illegal, g77 has the right to produce
anything it likes, but producing a wrong output without warning is a poor
handling of the error.
Regards,
Ryo
--
Summary: illegal E format descriptor produces 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
[Bug fortran/35036] illegal E format descriptor produces wrong output
--- 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, | | Can you cite from the Fortran 95 standard why this is illegal? Good question :-) Unfortunately, I don't have a Fortran 95 reference at hand, and so let me refer to the F77 standard: http://www.fortran.com/fortran/F77_std/rjcnf.html 13.5.9.2.2 E and D Editing. The Ew.d, Dw.d, and Ew.dEe edit descriptors indicate that the external field occupies w positions, the fractional part of which consists of d digits, unless a scale factor greater than one is in effect, and the exponent part consists of e digits. The e has no effect on input. [. . .] The scale factor k controls the decimal normalization (13.5.7). If -d < k <= 0, the output field contains exactly |k| leading zeros and d - |k| significant digits after the decimal point. If 0 < k < d + 2, the output field contains exactly k significant digits to the left of the decimal point and d - k + 1 significant digits to the right of the decimal point. Other values of k are not permitted. When d = 0, the only possible value for the scaling factor k is 1. Since "Other values of k are not permitted", you *must* use "1P" with d = 0, as "1PE8.0". Q.E.D. . . . I know this is a rather roundabout logic, and I'm not 100% sure, actually. I'm curious. Now, *if* "E8.0" is legal, what output should be generated for a value of 1e5 ? "0.E5" ? Cheers, Ryo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35036
[Bug fortran/35036] illegal E format descriptor produces wrong output
--- 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/output statement. The wording you quote | above is (almost) identical to F95 language, so one could argue | that the -d < k <= 0 is true when d = 0 and k = 0. 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 we quote? | In any event, gfortran is definitely giving a bogus answer | of 0E+1, and your desired output of *** is probably the | right thing to do. I like that. But, for the sake of curiosity, how does the Fortran standard describe the process that leads to ***? I mean, suppose E8.0 is legal, but still can we emit ***? Ryo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35036
[Bug fortran/35036] illegal E format descriptor produces wrong output
--- 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 we quote? | | Notice the "=". -d < k <= 0 goes to -(d=0) < (k=0) <= 0 --> -0 < 0 <= 0. | Zero is certainly less than or equal to zero. But, what about "-0 < 0"? Do you mean that this inequality holds? Do you mean to say minus integer zero is smaller than plus integer zero? | > I like that. But, for the sake of curiosity, how does the Fortran | > standard describe the process that leads to ***? I mean, suppose | > E8.0 is legal, but still can we emit ***? | | The *** are emitted when the result can't fit into the requested field. | Off the top of my head, the easiest example is E8.1E1 for x = 1e25. | The exponent field is too small, or I2 and i = 100. Yes, but do you claim that "the result can't fit into the requested field" for write(*, '(E8.0)') 1e5 supposing that E8.0 be legal? As you suggested, one "correct" output is "0.E+06", which would certainly "fit" in eight columns. Then why reject an output of "0.E+06" and replace it with "" ? What I'm getting at is that *if* E8.0 be legal and if you plan to emit "" for 1e5, you need a reason for that decision. Ryo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35036
[Bug fortran/56555] New: read from pipe
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 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fu...@hawaii.edu When reading from stdin in a simple pipe, the Fortran runtime reports an "End of file" error. See the self contained example below. It was done on a Debian-testing system. The shell is a symlink to /bin/dash . Regards, Ryo --- $ cat try.f90 program try real(4):: r integer:: i do !! infinite loop read(*,*) r write(*,*) r end do end program try $ gfortran -o try try.f90 $ cat try.sh #!/bin/sh for n in `seq 1 10`; do echo $n | ./try done $ sh try.sh 1. At line 5 of file try.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file 2. At line 5 of file try.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file 3. At line 5 of file try.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file 4. At line 5 of file try.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file 5. At line 5 of file try.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file 6. At line 5 of file try.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file 7. At line 5 of file try.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file 8. At line 5 of file try.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file 9. At line 5 of file try.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file 10.000 At line 5 of file try.f90 (unit = 5, file = 'stdin') Fortran runtime error: End of file $
[Bug fortran/56555] read from pipe
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
[Bug fortran/56555] read from pipe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56555 Ryo Furue changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Ryo Furue 2013-03-07 00:36:11 UTC --- I'm not sure this is the right thing to do, but I'll try to close this bogus report by labeling it as "invalid". Hope it works. Sorry again.
[Bug fortran/57628] New: spurious error: division by zero in if statement
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
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 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
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 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
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 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
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 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
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 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
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 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
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
[Bug fortran/57628] spurious error: division by zero in if statement
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. > 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
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 ? > > No. Then, what's the counterpart of -fno-range-check that takes care of such cases as sqrt? To repeat the code: 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. Or is it better to extend -fno-range-check to cover these cases, too? Cheers, Ryo
[Bug fortran/57628] spurious error: division by zero in if statement
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 > > 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
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 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
[Bug fortran/99506] New: internal compiler error: in record_reference, at cgraphbuild.c:64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99506 Bug ID: 99506 Summary: internal compiler error: in record_reference, at cgraphbuild.c:64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal 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 source files. The internal compiler error happens with GNU Fortran (Homebrew GCC 10.2.0_4) 10.2.0 . The homebrew maintainer confirms this error and further reports that the same error occurs on Ubuntu, too (I don't know the version of gfortran). See https://github.com/Homebrew/homebrew-core/issues/72865 . The maintainer recommends submitting this report here. Expand the attached tar file, cd to that directory, and on the command line: $ gfortran -c numeric_kinds.f90 $ gfortran -c indices.f90 $ gfortran fix-track-partials-00.f90 indices.o f951: internal compiler error: in record_reference, at cgraphbuild.c:64 libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See <https://github.com/Homebrew/homebrew-core/issues> for instructions. In the above the dollar symbols is the command prompt.
[Bug fortran/99506] internal compiler error: in record_reference, at cgraphbuild.c:64
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)/100.d0, j=1,jmax)] The "i" in "latt100(i)" is wrong. I meant "j".
