the PRESENT test of an optional variable returns TRUE in both of these calls $ cat c.F; gfortran c.F ; ./a.out PROGRAM MAIN REAL A INTEGER I CALL SUB(A,I) CALL SUB(A) END SUBROUTINE SUB(A,I) REAL :: A INTEGER, OPTIONAL :: I IF (PRESENT(I)) THEN PRINT *,'YES' ELSE PRINT *,'NO' END IF END YES YES c.f intel gives $ ifort c.F ; ./a.out YES NO gfortran behaves correctly with an explicit INTERFACE, but that should not be required (as far as I know) Olav
> gfortran behaves correctly with an explicit INTERFACE, but that > should not be required (as far as I know) Explicit interfaces are required for procedures with optional arguments. SUB is still external to MAIN, so is defined implicitly in MAIN. As far as I can see it's not legal. I don't know what ifort's doing. Shouldn't this error be detected by the compiler at some stage of the compilation? Or rather: Having the compiler detect this and raise an error would be a nice feature.
Subject: Re: present returns wrong value of optional variables On Wed, 2007-11-28 at 10:33 +0000, terry at chem dot gu dot se wrote: > Shouldn't this error be detected by the compiler at some stage of the > compilation? Or rather: Having the compiler detect this and raise an error > would be a nice feature. > > OK, thanks. I realize the difficulty here when routines are complied separately, but perhaps a warning might be possible at the linking stage... Olav
If no explicit interface is known, the following produces is almost all cases invalid code: CALL SUB(A,I) CALL SUB(A) Other compilers detect this such as NAG f95: Error: line 5: Different number of arguments from the first call of SUB or g95: Warning (154): Inconsistent number of arguments in reference to 'sub' at (1) and (2) > OK, thanks. I realize the difficulty here when routines are complied > separately Currently, gfortran does not do in-file consistency checks. Though this is planned. It won't help for if they are compiled separately. > but perhaps a warning might be possible at the linking stage... No, the linking is done by the linker and not the compiler and it has not such knowledge. It only sees whether a symbol ("sub_") can be resolved or not.
Whole-file checking does not catch this (yet). I'd think that it should be possible to generate a warning here. $> $ gfortran-svn -Wall -W -fwhole-file pr34260.f pr34260.f:1.22: SUBROUTINE SUB(A,I) 1 Warning: Unused dummy argument 'a' at (1) gcc version 4.6.0 20100501 (experimental) (GCC)
Subject: Bug 34260 Author: dfranke Date: Tue May 25 18:10:01 2010 New Revision: 159838 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159838 Log: gcc/fortran/: 2010-05-25 Daniel Franke <franke.daniel@gmail.com> PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Add check for global procedures with implicit interfaces and assumed-shape or optional dummy arguments. Verify that function return type, kind and string lengths match. gcc/testsuite/: 2010-05-25 Daniel Franke <franke.daniel@gmail.com> PR fortran/30668 PR fortran/31346 PR fortran/34260 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_16.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_17.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr40999.f trunk/gcc/testsuite/gfortran.dg/whole_file_5.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_6.f90
Commit in #5 catches the OPTIONAL argument if the testcase is compiled with -fwhole-file. However, the warning regarding the inconsistent use of SUB is still missing.
Subject: Bug 34260 Author: dfranke Date: Sun Jul 18 20:49:30 2010 New Revision: 162287 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162287 Log: gcc/fortran/: 2010-07-18 Daniel Franke <franke.daniel@gmail.com> Paul Thomas <pault@gcc.gnu.org> PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Improved checking if an explicit interface is required. PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. gcc/testsuite/: 2010-07-18 Daniel Franke <franke.daniel@gmail.com> Paul Thomas <pault@gcc.gnu.org> PR fortran/30668 PR fortran/31346 PR fortran/34260 PR fortran/40011 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. * gfortran.dg/whole_file_19.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90
Fixed in trunk and 4.5. Closing.