do real_var = 0.0, 10.0, 0.1 print *, real_var end do is valid Fortran 77 (not in 66) but it was deleted from newer Fortran standards. gfortran barks if it finds one, but instead of printing one error message it prints four (loop variable, start, end and increment), which is a bit too much. Expected: There is only one warning message printed. a.f90:4.6: do x =0., 10., dx 1 Warning: Deleted feature: Loop variable at (1) must be integer a.f90:4.8: do x =0., 10., dx 1 Warning: Deleted feature: Start expression in DO loop at (1) must be integer a.f90:4.11: do x =0., 10., dx 1 Warning: Deleted feature: End expression in DO loop at (1) must be integer a.f90:4.16: do x =0., 10., dx 1 Warning: Deleted feature: Step expression in DO loop at (1) must be integer
I disagree with you as does the F95 standard (if I'm not misreading the standard). 1.5 Conformance (3) It contains the capability to detect and report the use within a submitted program unit of an additional form or relationship that is not permitted by the numbered syntax rules or their associated constraints, including the deleted features described in Annex B; The F95 standard explicitly lists a constraint that the do-variable is an INTEGER. It also explicitly lists that start, end, and step are scalar-int-expr. By 1.5(3), gfortran must provide a means to detect and report the (mis)uses of 'do x = 0., 10. 0.1'. That's 4 warnings.
(In reply to comment #1) > I disagree with you as does the F95 standard Sorry, I cannot find anywhere in the standard that one has to emit four warnings. First, I think that one warning for a real loop variable is enough (if the loop variable is integer, but e.g. step is real, I of cause expect a warning there). Second, one can also emit a warning stating: Warning: Deleted feature: Loop variable and start, stop, and step expression at (1) must [all] be integer [but are all real] where [...] is optional text to really stress that all four constrains are violated.
(In reply to comment #2) > (In reply to comment #1) > > I disagree with you as does the F95 standard > > Sorry, I cannot find anywhere in the standard that one has to emit four > warnings. I quoted the relevant text from F95. See comment #1. The standards requires that a conforming processor "detect and report the use ... including the deleted features" I don't care if it's one warning or 4, but all 4 deleted features in 'do x = 0., 10., 0.1' must be detected and reported. Gfortran's current behavior is conforming. To be clear, there are 16 possible combinations (and I'm not distinguishing between the various REAL kind type parameters). Are you going to construct correct (or at least sensible English) sentences for the various combinations? Why fix something that isn't broken and not very likely to occur when there are some many other things to do?
What shall we do with this, gents? A WONTFIX? Paul
I would like to see an option to silence gfortran in this regard - having it as default warning is fine, but maybe some -Wno-deleted option could be added then? Or like g95 and ifort have (gcc/g++ as well?) a fine tuning of the warning to disable such warnings. Having only one warning (and skipping the others if one has been printed) is just one option to reduce the clutter of default warnings if one compiles a legacy program, which one does not want to rewrite.
(In reply to comment #5) > I would like to see an option to silence gfortran in this regard - having it as > default warning is fine, but maybe some -Wno-deleted option could be added > then? Isn't this what -std=* is for? The snippet in #0 gives exactly one error for -std=f95, no warning or error for -std=legacy and four warnings with -std=gnu. I'd vote for closing as WONTFIX or INVALID.
This is not invalid and is a feature request. I do think that -w will silence warnings. I do not see a need to treat this particular warning any differently then all the rest of the legacy warnings we have. For example, to run the NIST test suite, I use -w in the script because there are hundreds of warnings. OTOH I can see where a program that has a lot of real do loops would be irritating. I think that the standard does not explicitly say issue four warnings as long as each is detected. I am using "detected" in the sense that each is found and we issue a broader warning message. So I suggest we mark as an enhancement and when some one has time, we could implement a consolidated error message.
(In reply to comment #7) > OTOH I can see where a program that has a lot of real do loops would be > irritating.[...] So I suggest we mark as an enhancement and when some one has > time, we could implement a consolidated error message. This could backfire. Consider applications that make extensive use of computed GOTOs, PAUSE or any of the other deleted features. Shall we introduce flags for selectively enable/disable any of them? That's what -std={legacy|gnu|f*} does.
(In reply to comment #8) > This could backfire. Consider applications that make extensive use of computed > GOTOs, PAUSE or any of the other deleted features. Shall we introduce flags for > selectively enable/disable any of them? That's what -std={legacy|gnu|f*} does. I am in favour of doing so at some point - that's what other compilers also have: a) g95 has numbers associated to warnings ("Warning (137): ....") and has the options: -Werror=numbers Change the comma-separated list of warnings into errors. -Wno=numbers Disable a comma separated list of warnings indicated by numbers. b) ifort also has numbers ("remark #7712: ...") -diag-* options, e.g. "-diag-disable 7712" c) gcc: It at least attaches the option name after the warning and offers a more fine-grained control; example for the former: aaa.c:3:6: warning: unused variable ‘i’ [-Wunused-variable] ^^^^^^^^^^^^^^^^^^^ (Enabled by default; controllable via -fdiagnostics-show-option - gfortran currently ignores this option.)
(In reply to comment #7) > > OTOH I can see where a program that has a lot of real do loops would be > irritating. I think that the standard does not explicitly say issue four > warnings as long as each is detected. I am using "detected" in the sense that > each is found and we issue a broader warning message. > See comment #1 and #3. The standard explicitly states that a Fortran processor must "detect and report" the use of deleted features. The do-variable, start, end, and stride are independent entities and each should generate a warning. If you don't want to see possibly 4 warnings, then use -std=legacy or -w or fix the problem. I also suspect that if one doesn't want to see these warnings, one doesn't want to see any other warnings related to legacy features.
(In reply to comment #10) > See comment #1 and #3. The standard explicitly states that a Fortran > processor must "detect and report" the use of deleted features. It must report them - but the standard does not tell how often thus telling the user: "your program uses somewhere a deleted feature - find out yourself which one and where" is also standard conforming - albeit not very helpful. > I also suspect that if one doesn't want to see these warnings, one doesn't want to see > any other warnings related to legacy features. Well, if I happen to use such a legacy program, I am interested to get warnings to find out whether there is a problem (e.g. uninitialized variables) though fortunately I do not have to deal often which such code.
Written six years ago > What shall we do with this, gents? > > A WONTFIX? > > Paul Any point to keep this PR opened?
> Any point to keep this PR opened? No feedback, closing as WONTFIX.