[Bug fortran/57711] New: Fortran 4.7.2/4.8.1 error: constraints for functions parameters

[Bug fortran/57711] New: Fortran 4.7.2/4.8.1 error: constraints for functions parameters

[kabanovdmitry at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711

            Bug ID: 57711
           Summary: Fortran 4.7.2/4.8.1 error: constraints for functions
                    parameters
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kabanovdmitry at gmail dot com

I try to compile the fortran program which my advisor gave me.

It doesn't want to compile when I'm doing this with gfortran 4.7.2 on Mac OS X
10.8.4 and with gfortran 4.8.1 on Arch Linux x64.

I've built the minimal working example which replays the error. Unfortunately,
it's quite big anyway, so I've put it on the github:
https://github.com/kabanovdmitry/vode-test

I can compile this code under Ubuntu 12.04 with gfortran 4.6.3.

I've checked press releases for GCC 4.7 and found nothing that could give me a
clue.

Seems like gfortran's rules for functions parameters became stricter without an
announcement.

[Bug fortran/57711] Fortran 4.7.2/4.8.1 error: constraints for functions parameters

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-06-25
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(1) What error(s) do you get?
(2) Are you sure that you can compile the code you have posted with 4.6.3?
(3) could you further reduce vode.f?

[Bug fortran/57711] Fortran 4.7.2/4.8.1 error: constraints for functions parameters

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
First, you have a *serious* bug in JAC/DUMMY_JAC:

Namely, in DUMMY_JAC you have:
    double precision, intent(inout) :: RPAR(:)
    integer, intent(inout) :: IPAR(:)
(Those have ASSUMED-SHAPE arrays)

And in JAC:
          DOUBLE PRECISION, INTENT(INOUT) :: RPAR(*)
          INTEGER, INTENT(INOUT) :: IPAR(*)
(And those are ASSUMED-SIZE arrays.)

But for procedures declarations and its interface declarations, either both or
neither has to use assumed-shape arrays. The compilers passes (internally)
arguments quite differently - thus (unless the compiler detects it) it will
cause problems at run time.


Secondly and regrading gfortran:
* For some reasons, it compiles with GCC 4.7 if one calls D_VODE instead of
VODE.
* The error message for generic matching should be better (cf. PR40276). When
checking the interface of dummy procedure, it should be possible to give always
an error.

[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711

Tobias Burnus <burnus at gcc dot gnu.org> 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 <burnus at gcc dot gnu.org> ---
(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

[Bug fortran/57711] Accepts non-matching invalid dummy procedure as actual argument

[kabanovdmitry at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711

--- Comment #4 from Dmitry Kabanov <kabanovdmitry at gmail dot com> ---
@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

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(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

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
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.