Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Allocation problems within a type

eddie_breeveld
Beginner
1,638 Views

The following program compiles, but produces a run-time error (forrtl: severe (151): allocatable array is already allocated):

program Console2

type :: Dimensions

character*(20), allocatable, dimension(:) :: dimensions

end type Dimensions

type (Dimensions) :: fixed_array1_names

!!deallocate (fixed_array1_names%dimensions)

allocate (fixed_array1_names%dimensions(3))

fixed_array1_names%dimensions =(/'units', 'tens', 'hundreds'/)

end program Console2

If I remove the comment and include the deallocate, I get a Visual C++ pop-up error: Debug assertion failed, Expression _CrtIsValidheapPointer(pUserData) at the deallocate.

I'm doing something wrong, but I can't think what! Can anybody please enlighten me?

All the best,

0 Kudos
8 Replies
Jugoslav_Dujic
Valued Contributor II
1,638 Views

I'm not yet very familiar with allocatable TR, but your example looks legal to me -- except that it's odd that all strings within constructor should have the same length (i.e. you should insert trailing spaces manually) -- but that isn't supposed to be related?

Yet, there's a subtle difference between allocatable_entity and allocatable_entity(:) under TR/F2003. Namely:

fixed_array1_names%dimensions = (/'a', 'b', 'c'/)

is supposed to a)check the actual SIZE(dimensions) b) if it doesn't match the right-hand size, deallocate it c) allocate it to right-hand size and d) assign, while

fixed_array1_names%dimensions(:) = (/'a', 'b', 'c'/)

is just a normal arrayassignment (subject to possible array-bounds checking failure).

Thus, except for above-mentioned length mismatch, your example looks OK to me (and theALLOCATE lineis actually unnecessary) -- but try it with (:) and see what happens. If I'm right, you discovered a compiler bug.

Take my words with a grain of salt as it's quite possible that I mixed up what's in allocatable TR (supported by CVF/IVF) and what's new in Fortran 2003 (not supported by CVF/IVF). Steve?

Jugoslav

0 Kudos
eddie_breeveld
Beginner
1,638 Views
Good idea, I also tried in in CVF and either way works fine - but not IVF. I'll submit another bug report to Intel (number three in as many days). Thanks for your help Jugoslav.
ps - All your'colon-bracket's are being translated into smilies!
0 Kudos
Jugoslav_Dujic
Valued Contributor II
1,638 Views
Does it work the other way (with smiley :smileyvery-happy:) in IVF?
0 Kudos
eddie_breeveld
Beginner
1,638 Views

Your last reply seems to have gone smiley mad ;-)

With both IVF and CVF, variable length strings seem to beallowed (i.e., padding is not required) in the assignment.

I cannot get any version to work at run-time(with or without (:), with or without the allocate, with or without the deallocate) in IVF. I've put in a bug report.

Interestingly, but when I think about it not surprisingly, one of my previous IVF bugs is also a CVF bug.

All the best,

0 Kudos
Steven_L_Intel1
Employee
1,638 Views
I am trying to get the punctuation smileys disabled in the forum. Supposedly, it will happen soon....
0 Kudos
Jugoslav_Dujic
Valued Contributor II
1,638 Views
Re smileys: I think it's perfectly OK to enable parsing of smileys in form :smileytongue:, but not in short form, like :)
Now both seems to be gone :-(.
Jugoslav
0 Kudos
Steven_L_Intel1
Employee
1,638 Views
Yes, that's exactly what I asked for - the :smiley: syntax recognized (this is what the button gives you), but punctuation sequences not turned into smileys. Let's see if they did it... :smileytongue:
Sigh - well, half right, anyway...

Message Edited by sblionel on 03-06-2004 06:55 PM

0 Kudos
Steven_L_Intel1
Employee
1,638 Views
I had asked that the syntax with the colons, as the button gives you, continue to work. I'll have to ask again...
0 Kudos
Reply