topic Problem with OPTIONAL in Intel® Fortran Compiler

Problem with OPTIONAL

dajum — Tue, 03 Jan 2012 20:35:10 GMT

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)

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

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

Problem with OPTIONAL

lklawrie — Tue, 03 Jan 2012 20:42:06 GMT

I get false.

(after modifying it a bit for free format f90)

Problem with OPTIONAL

dajum — Tue, 03 Jan 2012 20:52:48 GMT

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.

Problem with OPTIONAL

lklawrie — Tue, 03 Jan 2012 21:35:18 GMT

if it makes a difference i was using v12.

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

Problem with OPTIONAL

Anonymous66 — Tue, 03 Jan 2012 21:45:25 GMT

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

Problem with OPTIONAL

dajum — Tue, 03 Jan 2012 21:50:00 GMT

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

Dave

Problem with OPTIONAL

dajum — Tue, 03 Jan 2012 21:51:31 GMT

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

Microsoft Incremental Linker Version 9.00.30729.01

-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

Problem with OPTIONAL

Steven_L_Intel1 — Tue, 03 Jan 2012 21:56:53 GMT

An explicit interface is required here. Read this.

Problem with OPTIONAL

dajum — Tue, 03 Jan 2012 22:04:52 GMT

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

Dave

Problem with OPTIONAL

lklawrie — Wed, 04 Jan 2012 14:43:59 GMT

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

Problem with OPTIONAL

Steven_L_Intel1 — Wed, 04 Jan 2012 15:35:47 GMT

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.

Problem with OPTIONAL

lklawrie — Wed, 04 Jan 2012 15:55:28 GMT

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

Problem with OPTIONAL

Steven_L_Intel1 — Wed, 04 Jan 2012 16:17:26 GMT

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.

Problem with OPTIONAL

lklawrie — Wed, 04 Jan 2012 16:24:07 GMT

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.

Problem with OPTIONAL

Steven_L_Intel1 — Wed, 04 Jan 2012 16:31:29 GMT

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.

Problem with OPTIONAL

dajum — Wed, 04 Jan 2012 16:47:38 GMT

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?

Problem with OPTIONAL

Steven_L_Intel1 — Wed, 04 Jan 2012 19:11:08 GMT

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.

Problem with OPTIONAL

Steven_L_Intel1 — Mon, 12 Mar 2012 16:00:11 GMT

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