Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29271 ディスカッション

ALLOCATED Compiling Error

jkrob
ビギナー
1,105件の閲覧回数

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

0 件の賞賛
1 解決策
IDZ_A_Intel
従業員
1,105件の閲覧回数
Again, it suggests a data corruption issue. Variables may be laid out differently in memory causing the error to go undetected before.

元の投稿で解決策を見る

6 返答(返信)
IDZ_A_Intel
従業員
1,105件の閲覧回数

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
従業員
1,105件の閲覧回数

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
ビギナー
1,105件の閲覧回数

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
従業員
1,105件の閲覧回数

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
ビギナー
1,105件の閲覧回数

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
従業員
1,106件の閲覧回数
Again, it suggests a data corruption issue. Variables may be laid out differently in memory causing the error to go undetected before.
返信