topic Re: Another static verification question in Intel® Fortran Compiler

Another static verification question

Intel_C_Intel — Thu, 24 Jan 2008 15:20:37 GMT

I'm using the Intel Fortran compiler 10.1.011 [IA32] and just found out about the static verification capability. This was very good news to me as we were struggling to find the source of a small problem that caused very bad results. Static verification helped to very quickly find the cause of this issue. We have about 42000 lines of code and there still many errors from the static verification that I'd like to handle better. Unfortunately, I find no information explainingthe error messages much less information on how to resolve them. One of the most perplexing messages is: error #12292: [SV] "" has wrong value for deallocation. I have these variables initially declared, then allocated to the appropriate size and at the end of the routine, I have a standard deallocate statement to release the memory, shown below:

DEALLOCATE (U1,U2,WLX1,WLX2,V1,V2,WLY1,WLY2)

RETURN

END SUBROUTINE BC_CARD

I get 8 error messages from the DEALLOCATE statement and then 8 more from the END SUBROUTINE line and I understand none of the reasons why. It doesn't affect all of the variables in my DEALLOCATE statements, just some. Any ideas?

Thanks, Mitchell Brown

Re: Another static verification question

Les_Neilson — Thu, 24 Jan 2008 16:49:18 GMT

I prefer to allocate and deallocate arrays individually. When deallocating I first check that ithasan allocatedstatus :

if (allocated(array)) deallocate(array, stat=ierr)
do some test/message with ierr not equal zero

also I tend to deallocate in reverse order to the original allocation (LIFO). I don't know if this is really necessary but it is a habit I got into early on. (Originally because someone suggested it improved garbage collection.)

Then if an error occurs onan array I know which one and ierr gives the error code.
Finally if the allocation/deallocation are done in the same routine you could safely remove the deallocate because the arrays are automagically deallocated when they go out of scope.

Les

Re: Another static verification question

Steven_L_Intel1 — Thu, 24 Jan 2008 17:26:44 GMT

Can you show a short but complete routine that demonstrates the problem with SV? I have seen some "false alarms" with SV but not this one in particular. The messages from the end of the routine are likely due to automatic deallocation of local allocatable variables and may be incorrect too.

Re: Another static verification question

jimdempseyatthecove — Thu, 24 Jan 2008 18:56:46 GMT

Mitchell,

If you are not using IMPLICIT NONE it is possible that you are deallocating GNW (God know what). Generally, the allocatable arrays are inside a module, but in conversion of old code to new code you may have some of these arrays or dangling DIMENSIONs laying around. A third thing is if you have samed named arrays in different modules and youuse the wrong module name in one or the other places.

As another poster suggested do the deallocations one at a time and conditionally.

if(allocated(D1)) deallocate(D1)
...

You may also want to insert some diagnostic code (enabled by a conditional) that asserts that the arrays to be returned are indeed allocated (as opposed to conditionally deallocating them).

Re: Another static verification question

Intel_C_Intel — Thu, 24 Jan 2008 19:34:08 GMT

See below for short, though not complete subroutine. Each of the routines having difficulty that I have gotten to so far are fairly complex. If you want the routine intact, I would prefer to send directly to you. I will attempt to allocate and deallocate separately as recommended by user above.

SUBROUTINE BC_CARD(ICONT, HOUR, HOTFIL, DT)
... (USE MODULES not displayed)

IMPLICIT NONE
... (VARIABLE DECS not displayed)

REAL,ALLOCATABLE :: U1(:),U2(:),WLX1(:),WLX2(:)
REAL,ALLOCATABLE :: V1(:),V2(:),WLY1(:),WLY2(:)

ALLOCATE (U1(L1),U2(L1),WLX1(L1),WLX2(L1))
ALLOCATE (V1(M1),V2(M1),WLY1(M1),WLY2(M1))

IF(ICONT == 1) THEN
... (portion not displayed)
CALL XF_READ_SCALAR_VALUES_TIMESTEP (UID1,TIMINC,L1,U1,ERROR)
CALL XF_READ_SCALAR_VALUES_TIMESTEP (UID2,TIMINC,L1,U2,ERROR)
CALL XF_READ_SCALAR_VALUES_TIMESTEP (VID1,TIMINC,M1,V1,ERROR)
CALL XF_READ_SCALAR_VALUES_TIMESTEP (VID2,TIMINC,M1,V2,ERROR)
CALL XF_READ_SCALAR_VALUES_TIMESTEP (WLXID1,TIMINC,L1,WLX1,ERROR)
CALL XF_READ_SCALAR_VALUES_TIMESTEP (WLXID2,TIMINC,L1,WLX2,ERROR)
CALL XF_READ_SCALAR_VALUES_TIMESTEP (WLYID1,TIMINC,M1,WLY1,ERROR)
CALL XF_READ_SCALAR_VALUES_TIMESTEP (WLYID2,TIMINC,M1,WLY2,ERROR)
ELSE
... (portion not displayed)
CALL XF_WRITE_SCALAR_TIMESTEP (UID1,HOUR,L1,U1,ERROR)
CALL XF_WRITE_SCALAR_TIMESTEP (UID2,HOUR,L1,U2,ERROR)
CALL XF_WRITE_SCALAR_TIMESTEP (VID1,HOUR,M1,V1,ERROR)
CALL XF_WRITE_SCALAR_TIMESTEP (VID2,HOUR,M1,V2,ERROR)
CALL XF_WRITE_SCALAR_TIMESTEP (WLXID1,HOUR,L1,WLX1,ERROR)
CALL XF_WRITE_SCALAR_TIMESTEP (WLXID2,HOUR,L1,WLX2,ERROR)
CALL XF_WRITE_SCALAR_TIMESTEP (WLYID1,HOUR,M1,WLY1,ERROR)
CALL XF_WRITE_SCALAR_TIMESTEP (WLYID2,HOUR,M1,WLY2,ERROR)
ENDIF
... (portion not displayed)
DEALLOCATE (U1,U2,WLX1,WLX2)
DEALLOCATE (V1,V2,WLY1,WLY2)

RETURN
END SUBROUTINE BC_CARD

Re: Another static verification question

Steven_L_Intel1 — Thu, 24 Jan 2008 20:13:46 GMT

Please create an issue at Intel Premier Support, attach the complete source and ask that it be assigned to Steve Lionel.

Re: Another static verification question

Intel_C_Intel — Thu, 24 Jan 2008 20:22:53 GMT

Creating the issue now. Will provide entire project. Thanks

Re: Another static verification question

jimdempseyatthecove — Fri, 25 Jan 2008 00:31:25 GMT

Mitchell,

Some suggestions while you are waiting

Insert

100 CONTINUE(appropriately numbered CONTINUE)

In front of the 1st DEALLOCATE

Place a GOTO 100 after the last ALLOCATE (goes to the first DEALLOCATE)

Compile and run with Break Point at END SUBROUTINE.(Or simply place break point on IF(ICONT == 1) then use Set Next Statement to resume at the first DEALLOCATE.)

See what happens.

If the deallocations occure without complaint then move the GOTO 100 further down into the code (e.g. infron of the 1st CALL XF_..., both paths) and see if the deallocation complains.

Keep moving the GOTO 100 downwards. You can go in leaps leaving comment trails in the code.

The technique should identify where in the code that the array descriptors are getting clobbered.

Jim Dempsey