ALLOCATED Compiling Error

[jkrob]

All,

This issue applies to both my DVF 6.6 & IVF 11. I have an application which I have ported from DVF to IVF & I am trying to get to work. The program runs fine when compiled under CVF. When compiled under IVF, it compiles error free but the program hangs (but memory usagecontinues to increase slowly with time)when it runs into a line to DEALLOCATE an array. To test this issue, I have inserted an ALLOCATED test this way:

if(ALLOCATED(FLD)) DEALLOCATE (FLD)

When trying to compile with this change, I get the following errors with both CFV & IVF:

#6410: This name has not been declared as an array or a function. [ALLOCATED]

#6341: A logical data type is required in this context. [ALLOCATED]

Being an Intrinsic Function, I thought the usage would be fairly automatic & simple...what am I missing???

Thanks in advance,

Jeff

[IDZ_A_Intel]

Allocate/deallocate became available with F90.

Check your option switches to see if you are compiling as F77 (or earlier than F90). Note FOO.F assumes F77as default. FOO.F90 assumes F90, F95, ... as default.

Jim Dempsey

[IDZ_A_Intel]

There is no "compiling as F77" option - fixed form source is still compiled as Fortran 2003.

Please show an actual source file that demonstrates this behavior. My guess is that you have added something that prevents ALLOCATED from being recognized as an intrinsic.

[jkrob]

Thanks Steve,

The compile issue wasthat I hadoriginally assigned the LOGICAL ALLOCATED as .false. down in the middle of the code so when I added the IF (ALLOCATED(FOO)) line, IVF complained. That is what I get when trying to do work at 1am ;-)

However...the IVF code still hangs when it comes to the DEALLOCATE functions where it worked in CVF. The IVF codes I have for the other programs in my package from CVF work with the ALLOCATE/DEALLOCATE fine so would a specific library or USE function muck something like this up?

BTW - there are several hundred subroutines associated with this program so to send it to you to troubleshoot would be quite involved...

Thanks again,

Jeff

[IDZ_A_Intel]

I thought it might be something like that. This is why I always grimace when someone "describes" their code rather than showing it.

The hang on the DEALLOCATE is possibly due to data corruption - but finding that can be difficult. When it hangs does the process go CPU-bound?

[jkrob]

Regretfully, the process is CPU-bound for the full operation because it is converting a data file to another format. At the end of the routine, when it is releasing it's resources at the DEALLOCATE function, the CPU usage does not really change. The only difference is that the memory starts to be consumed at about 300 KB per secondwhich...is about the size of the array it is trying to release.

This was also an issue in one of the other subroutines in this program and as soon as I converted the arrays from dynamic to static size, it quit hanging at where that DEALLOCATE point used to be & progressed on through the code it issupposed to. It was not so much an issue with those arrays because they could be set at a fixed size but the arrays that I'm dealing with now have the potential of needing to be more dynamic in size because it is selectable by the user & I'd rather not have to fix some huge size for the 'potential' of what the user 'might' need & run into stack size issues.

Again - this ALLOCATE/DEALLOCATE issue worked fine in CVF...interesting, eh?

Jeff

[IDZ_A_Intel · Accepted solution]

Again, it suggests a data corruption issue. Variables may be laid out differently in memory causing the error to go undetected before.