Problem with OPTIONAL

[dajum]

Can anyone tell me why the PRESENT function is returning TRUE for this even though there is no argument for the last 3 OPTIONAL arguments? I'm using 11.1.065, but seems the same in 12.1 as well.

Program test

integer m,nl(3)

Character*256 fname,modnam,arg2

arg2=' something'

modnam = 'all'

fname = 'test.me'

m = 1

nl(1)=2

call fluidic(m,arg2,fname,nl,modnam)

stop

end

SUBROUTINE FLUIDIC(MREC,NF,F1,N1,MODNAMIN,

x F2,N2,MODNAMIN2)

C

OPTIONAL F2

OPTIONAL N2

OPTIONAL MODNAMIN2

Character*32 F1(1),MODNAM,F2(1),MODNAM2

Character*(*) NF,MODNAMIN,MODNAMIN2

INTEGER N1(1),N2(1),MREC

LOGICAL DOPATHS

C

C

MODNAM = MODNAMIN(1:min(32,(3)))

DOPATHS = PRESENT(MODNAMIN2)

write(*,*)' the logical ',dopaths

IF( PRESENT(MODNAMIN2) ) THEN

MODNAM2 = MODNAMIN2(1:min(32,(3)))

DOPATHS = .TRUE.

ELSE

DOPATHS = .FALSE.

ENDIF

return

end

Thanks,

Dave

[lklawrie]

I get false.

(after modifying it a bit for free format f90)

[dajum]

I used a test.for file so I have fixed formating. I get TRUE. Every time. Maybe I will see if the formating makes a difference for me. Formatting didin't make a difference. f90 input still gets true.

[lklawrie]

if it makes a difference i was using v12.

attached here. added pause so that i could see results from inside the ide.

[Anonymous66]

I am getting false as well. I tried it with both 11.1.064 and 12.1 update 8.

What compiler flags are you using?

Annalee

Intel Developer Support

[dajum]

No flags. just "ifort test.f90" or "test.for" for the fixed source version. Both give F and crash for me.

Dave

[dajum]

c:\V55IVF64\sinda33\models>ifort test.f90

Intel Visual Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100414 Package ID: w_cprof_p_11.1.065

Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

Microsoft Incremental Linker Version 9.00.30729.01

Copyright (C) Microsoft Corporation. All rights reserved.

-out:test.exe

-subsystem:console

test.obj

c:\V55IVF64\sinda33\models>test

the logical T

forrtl: severe (157): Program Exception - access violation

Image PC Routine Line Source

test.exe 000000014003D7A3 Unknown Unknown Unknown

test.exe 0000000140001D4B Unknown Unknown Unknown

test.exe 0000000140001154 Unknown Unknown Unknown

test.exe 000000014005670C Unknown Unknown Unknown

test.exe 000000014003CDAB Unknown Unknown Unknown

kernel32.dll 000000007725F33D Unknown Unknown Unknown

ntdll.dll 0000000077392CC1 Unknown Unknown Unknown

[Steven_L_Intel1]

An explicit interface is required here. Read this.

[dajum]

Thanks! I missed that in the examples. But now it works fine for me.

Dave

[lklawrie]

And worked for me because I have it generate interfaces in the debug compile (or it does it by default):

!COMPILER-GENERATED INTERFACE MODULE: Tue Jan 03 13:41:12 2012
MODULE FLUIDIC__genmod
INTERFACE
SUBROUTINE FLUIDIC(MREC,NF,F1,N1,MODNAMIN,F2,N2,MODNAMIN2)
INTEGER(KIND=4) :: MREC
CHARACTER(*) :: NF
CHARACTER(LEN=32) :: F1(1)
INTEGER(KIND=4) :: N1(1)
CHARACTER(*) :: MODNAMIN
CHARACTER(LEN=32) ,OPTIONAL :: F2(1)
INTEGER(KIND=4) ,OPTIONAL :: N2(1)
CHARACTER(*) ,OPTIONAL :: MODNAMIN2
END SUBROUTINE FLUIDIC
END INTERFACE
END MODULE FLUIDIC__genmod

[Steven_L_Intel1]

Generated interfaces are not (supposed to be) used as a substitute for a required explicit interface - they are for diagnostic purposes only. However, we have had bugs in the past where the compiler went ahead and used the generated interface to change the code, and it looks like this is another one. I will report it to the developers.

[lklawrie]

The interface would not be necessary if the subroutine was "contained" in the program. Correct? Then it becomes part of that module?

[Steven_L_Intel1]

Correct. If the subroutine were in a module or was contained in the calling program, that would create the explicit interface. My general advice is that if you feel you have to write an INTERFACE block for Fortran code, you're doing it wrong, though I can appreciate that there are circumstances, such as updating old code, where this might be reasonable.

[lklawrie]

In general, I agree with that statement:

"My general advice is that if you feel you have to write an INTERFACE block for Fortran code, you're doing it wrong, though I can appreciate that there are circumstances, such as updating old code, where this might be reasonable."

I do like the ability to have a generic routine that in actuality spawns to other specific routines based on argument type.

[Steven_L_Intel1]

Generic interfaces are fine. It's when you write a specific interface that declares all the arguments, duplicating the declarations in the actuasl routine, where you can make trouble for yourself.

[dajum]

I'd like to know if there is a better way to do this, but I'm not sure I follow what you are suggesting. This routine is in a library that get called and linked by the users. So the main program and the code calling it can't contain it it. Is there some way besides an interface spec to do this?

[Steven_L_Intel1]

The better way is to put the subroutines in a module. Supply the users with the .mod and the .lib. The .mod provides the declarations and makes sure the routines are always called correctly.

[Steven_L_Intel1]

The reported problem has been fixed for a release later this year.