[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525 --- Comment #6 from Vittorio Zecca --- Still in trunk. The NAG nagfor and Intel ifort compilers detect the issue. ifort -S -w gfbug72.f gfbug72.f(4): error #6482: An ENTRY dummy argument is referenced in an executable statement before it appears in any ENTRY statement. [X] f(y)=x ! this is wrong ---^ compilation aborted for gfbug72.f (code 1) [vitti f95]$nagfor -S -w gfbug72.f NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042 Error: gfbug72.f, line 4: Dummy arg X used before first occurrence in an argument list [NAG Fortran Compiler error termination, 1 error]
[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525 --- Comment #5 from Dominique d'Humieres --- Duplicate of pr34663?
[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-22 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200321.
[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-27 07:56:20 UTC --- NAG has: Error: test.f90, line 2: Dummy arg X used before first occurrence in an argument list And ifort has: h4j.f90(2): error #6482: An ENTRY dummy argument is referenced in an executable statement before it appears in any ENTRY statement. [X] f(y)=x ! this is wrong ---^ The easiest fix is probably to check whether the symbol is already defined when parsing entry e(x) (or adding attr.dummy).
[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-27
12:12:03 UTC ---
I meant something like the following. Though, the wording could be improved.
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -4296,6 +4296,14 @@ gfc_match_formal_arglist (gfc_symbol *progname, int
st_flag, int null_flag)
if (gfc_get_symbol (name, NULL, sym))
goto cleanup;
+
+ if (sym-attr.referenced !sym-attr.dummy)
+ {
+ gfc_error (Argument '%s' at %C has been already used at %L,
+sym-name, sym-declared_at);
+ m = MATCH_ERROR;
+ goto cleanup;
+ }
}
p = gfc_get_formal_arglist ();
[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-27 14:27:39 UTC --- The patch causes regressions as it comes before the check in resolve_variable (search for before the ENTRY, which covers a similar issue (cf PR 25090). Namely: gfortran.dg/entry_dummy_ref_1.f90 gfortran.dg/entry_dummy_ref_2.f90 False positive - (n used in a specification expression): gfortran.dg/entry_array_specs_2.f * * * From the F2008 standard (12.6.2.6 ENTRY statement, para 7): In a subprogram, a name that appears as a dummy argument in an ENTRY statement shall not appear in an executable statement preceding that ENTRY statement, unless it also appears in a FUNCTION, SUBROUTINE, or ENTRY statement that precedes the executable statement. * * * Regarding resolve_variable: As cs_base == NULL, the existing check 5086 /* Deal with forward references to entries during resolve_code, to 5087 satisfy, at least partially, 12.5.2.5. */ 5088 if (gfc_current_ns-entries 5089 current_entry_id == sym-entry_id 5090 cs_base fails and, hence, there is no error. * * * Side remarks: a) before the ENTRY statement in which it is a parameter - Misuse of the term parameter b) warning: ‘master.0.sub’ defined but not used - Declare as DECL_ARTIFICIAL to avoid warning - or to handle it better if the warning itself makes sense.
