 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
simon
Joined: 05 Jul 2006
Posts: 270
|
 Posted: Thu Dec 08, 2022 1:23 am Post subject: Array lost in derived type |
 |
|
The following program defines a derived type at3 in terms of another derived type (at2), which in turn is defined as an array of yet another derived type (at1). Subroutine s is called to initialise an instance of at3, and then at3 is printed. However, only at3%c is printed, and at3%at2 appears to be missing.
| Code: | Module m
!
Type t1
Integer :: i1
Integer :: i2
End Type t1
!
Type t2
Type(t1), Dimension(2) :: at1
End Type t2
!
Type t3
Type(t2) :: at2
Character :: c
End Type t3
!
Type(t3), Dimension(:), Pointer, Public :: at3
!
Contains
!
!
Subroutine s ()
!
Allocate (at3(1))
at3(1)%at2%at1(:)%i1 = 1
at3(1)%at2%at1(:)%i2 = 1
at3(1)%c = 'A'
!
Return
End Subroutine s
End Module m
Program p
Use m
!
Call s ()
Print*, at3
End Program p |
|
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8016
Location: Salford, UK
|
| Posted: Thu Dec 08, 2022 8:26 am Post subject: |
|
|
Simon
I have logged this for investigation.
On initial investigation it appears that it is only the PRINT that is not working correctly. At the moment for the other components you need
| Code: | Print*, at3(1)%c
Print*, at3(1)%at2%at1
|
|
|
| Back to top |
|
|
simon
Joined: 05 Jul 2006
Posts: 270
|
| Posted: Thu Dec 08, 2022 3:12 pm Post subject: |
|
|
Hi Paul,
Indeed, in this case, it appears that only Print is not working, and printing individual components works, as in your example. However, I detected this problem in my much larger program because the components were getting lost when I was trying to use them for something else. If you need an example program to illustrate that problem I will try to create one, but I'd prefer to wait to see what you find out with the one already submitted, since it will take me a few hours. But I'll start on it asap if you are confident it will be helpful.
Thanks. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8016
Location: Salford, UK
|
| Posted: Thu Dec 08, 2022 4:13 pm Post subject: |
|
|
Simon
I think that it is unlikely that the error in the context of PRINT will reveal a more general error.
The issue is logged but it could be a few weeks before it is investigated. |
|
| Back to top |
|
|
simon
Joined: 05 Jul 2006
Posts: 270
|
| Posted: Wed Dec 14, 2022 9:06 pm Post subject: |
|
|
For what it's worth, the same problem occurs if the pointer is converted to an allocatable array:
| Code: | Module m
!
Type t1
Integer :: i1
Integer :: i2
End Type t1
!
Type t2
Type(t1), Dimension(2) :: at1
End Type t2
!
Type t3
Type(t2) :: at2
Character :: c
End Type t3
!
Type(t3), Dimension(:), Allocatable, Public :: at3
Type(t3), Dimension(:), Pointer, Public :: pt3
!
Contains
!
!
Subroutine s ()
!
Allocate (at3(1))
at3(1)%at2%at1(:)%i1 = 1
at3(1)%at2%at1(:)%i2 = 2
at3(1)%c = 'A'
!
Allocate (pt3(1))
pt3(1)%at2%at1(:)%i1 = 3
pt3(1)%at2%at1(:)%i2 = 4
pt3(1)%c = 'B'
!
Return
End Subroutine s
End Module m
Program p
Use m
Integer :: i
!
Call s ()
Print*, at3
Print*, pt3
i = at3(1)%at2%at1(1)%i1
Print*, i
i = pt3(1)%at2%at1(1)%i1
Print*, i
End Program p |
It may also be worth noting that if Type t3 is redefined as:
| Code: | Type t3
Character :: c
Type(t2) :: at2
End Type t3 |
Some of the initalized data are now output correctly, but that others appear to have random values, suggesting that they are unitialized.
I am very keen to get this problem resolved asap so I will work on trying to provide an example that applies to more than just Print ... |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8016
Location: Salford, UK
|
| Posted: Thu Dec 15, 2022 9:06 am Post subject: |
|
|
| Thank you for the additional feedback. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2584
Location: Sydney
|
| Posted: Fri Dec 16, 2022 7:46 am Post subject: |
|
|
Simon,
There are some approaches that might get around some of the problems you may have.
I have not needed extended derived types in my coding, while some allocatable components are acceptable.
I do find a general printed output of derived type to be problematic.
Do the following examples help ?
If not I would be interested in your comments as to why not.
| Code: | Module m
!
Type t2
Character :: c
Integer :: i1(2)
Integer :: i2(2)
End Type t2
!
Type tn
Character :: c
integer :: n
Integer,allocatable :: i1(:)
Integer,allocatable :: i2(:)
End Type tn
!
Type(t2), Dimension(:), Allocatable, Public :: at3
Type(tn), Dimension(:), Allocatable, Public :: pt3
!
Contains
!
!
Subroutine s ()
!
Allocate (at3(1))
at3(1)%i1 = 1
at3(1)%i2 = 2
at3(1)%c = 'A'
!
Allocate (pt3(1))
Allocate ( pt3(1)%i1(4) )
Allocate ( pt3(1)%i2(4) )
pt3(1)%n = 4
pt3(1)%c = 'B'
pt3(1)%i1 = 3
pt3(1)%i2 = 4
!
Return
End Subroutine s
End Module m
Program p
Use m
Integer :: i
!
Call s ()
Print*, at3
i = at3(1)%i1(1)
Print*, 'at3(1)%i1(1) =', i
! Print*, pt3(1) ! this is not allowed
Print*, pt3(1)%c, pt3(1)%i2
Print*, pt3(1)%n, pt3(1)%c, pt3(1)%i1
i = pt3(1)%i1(2)
Print*, 'pt3(1)%i1(2) =', i
End Program p |
|
|
| Back to top |
|
|
simon
Joined: 05 Jul 2006
Posts: 270
|
| Posted: Fri Dec 16, 2022 5:55 pm Post subject: |
|
|
John,
Your comments have set me thinking. First, let's remove c from the definition of t3, for simplification. Consider the following (I include all the code for ease of following):
| Code: |
Module m
!
Type t1
Integer :: i1
Integer :: i2
End Type t1
!
Type t2
Type(t1), Dimension(2) :: at1
End Type t2
!
Type t3
Type(t2) :: at2
End Type t3
!
Type(t3), Dimension(:), Pointer, Public :: pt3
!
Contains
!
!
Subroutine s ()
!
Allocate (pt3(1))
pt3(1)%at2%at1(:)%i1 = 3
pt3(1)%at2%at1(:)%i2 = 4
!
Return
End Subroutine s
End Module m
Program p
Use m
!
Call s ()
Print*, 'Output 1',pt3
Print*, 'Output 2',pt3(1)
Print*, 'Output 3',pt3(1)%at2%at1(1:2)
Print*, 'Output 4',pt3(1)%at2%at1(:)
Print*, 'Output 5',pt3(:)%at2%at1(1)
! Print*, 'Output 6',pt3(:)%at2%at1(:)
! Print*, 'Output 7',pt3(1:1)
End Program p
|
The code fails to compile at 'Output 6' in FTN95 if it is uncommented, and in at least one other compiler. But Outputs 1-5 compile, and all run correctly, except for Output 1 in FTN95. I would (naively?) expect Output6 to print everything but t3%c, which, to me, makes it a bit surprising that Output 1 works at all. The fact that Outputs 2-5 work, suggests to me that FTN95 has not resolved how to deal with the two implicit array components in Output 1.
The code at Output 7 also fails to compile, but other compilers accept this line and run as expected.
Maybe some of the above gives Paul a clearer clue as to what the problem might be. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8016
Location: Salford, UK
|
| Posted: Sat Dec 17, 2022 5:28 pm Post subject: |
|
|
Simon
I have had an initial look at this and I can see the failure for 'Output 1'.
The FTN95 processing at this point is specifically for PRINT. Given time it should be possible to fix it but it seems very unlikely that it will reveal any errors in a wider context.
Until we can provide a fix for this PRINT, I suggest that you avoid this particular form and let us know if you experience any failures in contexts other than I/O. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8016
Location: Salford, UK
|
| Posted: Mon Dec 19, 2022 8:36 am Post subject: |
|
|
This issue relates to PRINT/WRITE when printing a whole array of user type where the elements of the type include an array of user type.
At the moment it remains on the short list of known issues that need fixing.
It illustrates the complexities of Fortran compiler writing in that you can program horrendously complex processes in very short statements.
As far as I know there is no limit to the nesting of user TYPEs and their array members and you can write code that presents whole arrays (or array sections) at any of the nesting levels.
A Fortran programmer might assume that, the shorter the expression, the faster it will run. This is not always the case and (as illustrated in this context) could prove to be a "bridge too far". |
|
| Back to top |
|
|
simon
Joined: 05 Jul 2006
Posts: 270
|
| Posted: Mon Dec 19, 2022 5:07 pm Post subject: |
|
|
Hi Paul,
I'm sorry this is so complex. However, I believe that because John's response gave me a better sense of how to avoid the problem, I have a satisfactory work around. So I no longer consider this an urgent issue.
If I can isolate a case where the problem occurs outside of PRINT / WRITE, I will forward it.
Thanks. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8016
Location: Salford, UK
|
| Posted: Wed Jan 25, 2023 7:41 pm Post subject: |
|
|
| This bug has now been fixed for the next release of FTN95. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
