[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING CC||tkoenig at gcc dot gnu.org --- Comment #7 from Thomas Koenig --- I'm a bit confused about this PR. Is there anything to fix?
[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711
--- Comment #6 from Tobias Burnus ---
Patch for PR40276 and this PR:
http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html (approved).
It fails for the test case http://gcc.gnu.org/ml/fortran/2013-07/msg00017.html
(-> PR39290 and PR20896). In that test case, "s1" and "s2" are ambiguous in
F2003/F2008.
However, I fear that the check in the patch above will give a bogus error for
interface gen
subroutine s1(x)
real, external :: x
end subroutine s1
subroutine s1(x)
integer, external :: x
end subroutine s1
end interface
which is valid since F2008 ("both data objects or known to be functions, and
neither is TKR compatible with the other,", 12.4.3.4.5). The issue does not
occur yet, as the feature is not yet implemented.
[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711
--- Comment #5 from Tobias Burnus ---
(In reply to Dmitry Kabanov from comment #4)
> Regarding the bug in JAC/DUMMY_JAC: I think for one-dimensional arrays there
> is no difference between ASSUMED-SIZE and ASSUMED-SHAPE.
That's wrong:
- Assumed-size ("var(*)", "var(5,*)") and explicit size ("var(2,3)", "var(n,m)"
[the latter: automatic arrays]) pass a pointer to the data.
- Assumed-shape and deferred-shape ("var(:)") [and assumed-rank] pass a pointer
to an array descriptor (dope vector), which contains the array bounds - and a
pointer to the data.
Thus, mixing arrays from the first group with arrays from the second group does
not work. Thus, for procedures passed as argument (as your (dummy_)jac) the
array type has to be the same. And for normal array arguments, the compiler has
to know the interface* - otherwise it assumes that it is in the first group.
For array arguments, the compiler automatically converts between the two
groups.
(* know = its in a MODULE, in an internal procedure ("contains") or in an
INTERFACE block.)
> Anyway, the code compiles with gfortran 4.6.3.
My point was that they have a different internal representation. Thus, it will
fail at run time as soon as you access the array - either by having the wrong
value or by crashing.
Hence, you really should ensure that DUMMY_JAC and JAC either use both
assumed-shape arrays - or both assumed-size/explicit-size. (Mixing the latter
is fine in practice [if the compiler doesn't complain], even if it is not
permitted by the standard.)
If you corrected that bug, it should compile with both GCC 4.6 and GCC 4.7.
> I haven't found in press release of 4.7 any
> info confirming that gfortran changed its behavior regarding that matter
> intentionally. Is there any way to list all tasks which were included in
> some particular version of gfortran?
That change falls into the category bug fix/diagnostic improvement. The release
notes only list major, user visible changes:
http://gcc.gnu.org/gcc-4.7/changes.html
All changes are in the ChangeLog files. For the Fortran front end (w/o library
changes), you can find them at
http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/fortran/ for the current development
version - and for GCC 4.7 at
http://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_7-branch/gcc/fortran/
[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711 --- Comment #4 from Dmitry Kabanov --- @Dominique: a) I get the following error: make all gfortran -c vode.f gfortran -c fcns.f90 gfortran -c main.f90 main.f90:8.75: call vode(istate, lambda_fcn, dummy_jac, lambda, x_tmp, x_end, tol, pm) 1 Error: There is no specific subroutine for the generic 'vode' at (1) make: *** [all] Error 1 b) Yes, my collegue can compile the code with gfortran 4.6.3. Unfortunately, he uses different OS - Ubuntu 12.04. However, I think the problem is not connected to OS. c) I reduced vode.f such that it contains only function declaration of function and its arguments. @Tobias: Regarding the bug in JAC/DUMMY_JAC: I think for one-dimensional arrays there is no difference between ASSUMED-SIZE and ASSUMED-SHAPE. Anyway, the code compiles with gfortran 4.6.3. I haven't found in press release of 4.7 any info confirming that gfortran changed its behavior regarding that matter intentionally. Is there any way to list all tasks which were included in some particular version of gfortran?
[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711
Tobias Burnus changed:
What|Removed |Added
Keywords||accepts-invalid, diagnostic
Status|WAITING |NEW
Summary|Fortran 4.7.2/4.8.1 error: |Accepts non-matching
|constraints for functions |invalid dummy procedure as
|parameters |actual argument
--- Comment #3 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #2)
> * For some reasons, it compiles with GCC 4.7 if one calls D_VODE instead of
> VODE.
Ditto with GCC 4.9. -> ACCEPTS-INVALID bug
(For the test case: Change "call vode(" to "call d_vode(" in either the linked
code - or in the second test case of the patch below.)
> * The error message for generic matching should be better (cf. PR40276).
See patch at http://gcc.gnu.org/ml/fortran/2013-06/msg00132.html
