Home > Archive > Fortran > March 2006 > Derived types with derived types with allocatables
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Derived types with derived types with allocatables
|
|
|
| I followed up the recommendations I received in an earlier post and
changed, where possible, my pointers to allocatables in derived types.
One of the features that I can use now, as far as I understood, is:
A = B,
with A and B of the same type including allocatables. Where necesary A
will be allocated.
This works nicely when the type contains an allocatable array of, let's
say, integers (test1, see below), but it gives a segmentation fault if
the type contains an allocatable array of another type, that contains
an allocatable array of integers (ie. a nested structure) (see test2
below).
May I conclude that A = B works only in the case of non-nested
structures?
Please give some comments on this, as it has far stretching
consequences on how to set up my code.
Best regards,
Arno de Lange
! ----- test 1 ------
program test1
type e
integer,allocatable :: val(:)
end type
type (e) :: a,b
integer :: i
allocate (b%val(3))
a = b
write (*,*) 'size val=', size(a%val)
end program
! ----- test 2 ------
program test2
type e
integer,allocatable :: val(:)
end type
type d
type(e),allocatable :: sub(:)
end type
type (d) :: a,b
integer :: i
allocate (b%sub(3))
do i = 1,3
allocate(b%sub(i)%val(i))
enddo
a = b
write (*,*) 'size sub', size(a%sub)
end program
| |
|
| It think program test2 is fine. I.e. writes the expexted thing:
write (*,*) 'size sub', size(a%sub),
(size(a%sub(i)%val),i=1,size(a%sub))
end program
vondele@pcihopt1:~/g95> ./a.out
size sub 3 1 2 3
I assume that the compiler you've been using contains a bug for this
case, so you should ask your vendor for an upgrade.
Cheers,
Joost
| |
|
| I am using the intel compiler 9.0. They say TR 15881 is supported.
Arno
| |
|
| It works fine in their :
Version 9.0 Build 20051201Z Package ID: l_fc_c_9.0.031
(I also checked that g95,NAG,pgi give the right answer, but it also
triggers a bug in the IBM's xlf90)
Joost
| |
|
|
"Arno" <arnoinperu@hotmail.com> wrote in message
news:1143035970.268092.63190@i40g2000cwc.googlegroups.com...
> I am using the intel compiler 9.0. They say TR 15881 is supported.
>
> Arno
>
Both programs work with Intel version 9.0.030 printing size of 3
Adding the modified write from Joost, test2 prints size sub = 3 1 2 3
Les
| |
|
| ifort --version
ifort (IFORT) 9.0 20050430
Maybe, our build is sligthly older. assuming that 20050430 and 20051201
refer to dates, it might be that our (older) version still contained
bugs.
Thanks for your help.
Arno
| |
| Joe Krahn 2006-03-22, 7:03 pm |
| Arno wrote:
> ifort --version
>
> ifort (IFORT) 9.0 20050430
>
> Maybe, our build is sligthly older. assuming that 20050430 and 20051201
> refer to dates, it might be that our (older) version still contained
> bugs.
>
> Thanks for your help.
>
> Arno
>
There were some bug fixes related to TR-15881 features near the end of
2005, including one I reported for a segfault when allocating an
allocatable dummy argument. Intel seems to do a good job of fixing bugs
fairly quickly if you give them a good bug report.
Joe
| |
|
|
"Arno" <arnoinperu@hotmail.com> wrote in message
news:1143037740.674045.128050@z34g2000cwc.googlegroups.com...
> ifort --version
>
> ifort (IFORT) 9.0 20050430
>
> Maybe, our build is sligthly older. assuming that 20050430 and 20051201
> refer to dates, it might be that our (older) version still contained
> bugs.
>
> Thanks for your help.
>
> Arno
>
Yes the date on our version build is 20060222Z
Les
| |
| Rich Townsend 2006-03-22, 7:03 pm |
| Arno wrote:
> ifort --version
>
> ifort (IFORT) 9.0 20050430
>
> Maybe, our build is sligthly older. assuming that 20050430 and 20051201
> refer to dates, it might be that our (older) version still contained
> bugs.
>
> Thanks for your help.
>
> Arno
>
I think you're right. In fact, I recall submitting a bug report describing a
very similar problem, and IIRC the problem is fixed in the latest version of the
compiler.
cheers,
Rich
|
|
|
|
|