[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #6 from janus at gcc dot gnu.org 2011-09-10 10:18:58 UTC --- (In reply to comment #0) Fortran 2003's 12.4.1.3 Actual arguments associated with dummy procedure entities has about this: If the interface of the dummy argument is explicit, the characteristics listed in 12.2 shall be the same for the associated actual argument and the corresponding dummy argument, except that a pure actual argument may be associated with a dummy argument that is not pure and an elemental intrinsic actual procedure may be associated with a dummy procedure (which is prohibited from being elemental). Note: The same restrictions are already listed in F95's chapter 12.4.1.2, as well as F08's chapter 12.5.2.9. At first sight there are no differences between the different versions of the standard in the quoted passage.
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- Comment #5 from burnus at gcc dot gnu dot org 2008-04-11 07:45 --- If on the other hand Tobias is right in the assumption he made in comment #3, then one could something along the lines of if (f1-sym-as-type != f2-sym-as-type) I would not be surprised if foo(*) and foo(4) are allowed and then your test rejects too much. My feeling is that at least the array size should match for explicit-shape arrays, I'm not sure about that part; one can create valid (i.e. working) programs which violate this (e.g.: array(5), array(10), but only accessing 1 to 5). We should check what the standard says about this. I think it is formally invalid to do so; if we decide to allow it, at least a warning should be printed. (At the end one needs to carefully read the standard, unfortunately, I do not have much time the next two, three weeks. One could also ask at comp.lang.fortran.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- Comment #4 from jaydub66 at gmail dot com 2008-04-10 21:09 --- To me it's also not completely clear what the standard says on this, but the way to fix it would probably be to insert some additional check into operator_correspondence (interface.c), where currently only the type and rank of the arguments is checked. To require full equality of all array borders (as suggested in my comment #2), one could simply add if (!gfc_compare_array_spec (f1-sym-as, f2-sym-as)) return 1; into the above mentioned routine. This would result in gfortran behaving the same way as ifort in this case, may it be standard-conforming or not. If on the other hand Tobias is right in the assumption he made in comment #3, then one could something along the lines of if (f1-sym-as-type != f2-sym-as-type) return 1; to require only the array types to be equal, or something similar to at least prevent assumed-shape arrays from being passed instead of eplicit-shape arrays. My feeling is that at least the array size should match for explicit-shape arrays, but this is just a feeling and I couldn't find anything in the standard to confirm this. I'm not sure if the changes I'm suggesting would interfere with any other case where 'operator_correspondence' is called, but at least they don't seem to trigger any regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- Comment #2 from jaydub66 at gmail dot com 2008-04-09 18:23 --- Here is a modified version of the original test case, which is also accepted by gfortran, while it is rejected by ifort: module m contains subroutine one(a) integer a(1:2) end subroutine one subroutine two(a) integer a(2:3) end subroutine two end module program test use m implicit none ! PROCEDURE dummy !call foo(two) ! Interface dummy call bar(two) contains ! subroutine foo(f) ! procedure(one) :: f ! end subroutine foo subroutine bar(f) interface subroutine f(a) integer a(1:2) end subroutine f end interface end subroutine bar end program test In this test case both arrays are explicit-sized, and even have the same size, but their upper and lower bounds are shifted. gfortran currently does not even check if both arrays have the same size, only their ranks are compared. ifort gives the following error message: fortcom: Error: test35831.f90, line 23: The characteristics of dummy argument 1 of the associated actual procedure differ from the characteristics of dummy argument 1 of the dummy procedure. (12.2) [TWO] call bar(two) ---^ I would change this bug's status from UNCONFIRMED to NEW, but apparently I don't have the canconfirm permission. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-09 18:49 --- In this test case both arrays are explicit-sized, and even have the same size, but their upper and lower bounds are shifted. gfortran currently does not even check if both arrays have the same size, only their ranks are compared. I think procedures with explicit-shape arguments with the same shape/size but only different bounds should be conformable. The only real problem is assumed-shape vs. the rest (explict, assumed-size, ...). Ok, if an explicit size is given, the sizes should match, but arguments of the dummy/actual function like integer :: foo(*) and bar(1:2) and foobar(3000:3001) should all be conformable. Similarly, I think, also foo(1:), bar(:) and foobar(-300:) should be conformable. (I cannot really pinpoint it in the standard, but I'm convinced that this is the case; when I have time, I will re-read the standard and try to produce a proper reference.) * I use manner as kind and type have a special Fortran meaning. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-09 18:49:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
[Bug fortran/35831] Type-mismatch check missing for dummy procedure argument
--- Comment #1 from jaydub66 at gmail dot com 2008-04-08 20:58 --- Tobias, I can confirm the behaviour you described for this test case, provided of course that one and two are implemented somewhere externally. Otherwise one gets undefined reference to `two_' because there is only an interface for two but no actual implementation. Now, if I apply the fix for PR35830, i.e. adding the following line in copy_formal_args: formal_arg-sym-as = gfc_copy_array_spec (curr_arg-sym-as); Then also the error message for call foo(two) goes away! So this Type/rank mismatch in argument 'f' you saw before was apparently due to that array-handling bug in copy_formal_args! -- jaydub66 at gmail dot com changed: What|Removed |Added CC||jaydub66 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35831
