View previous topic :: View next topic |
Author |
Message |
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Sun Jun 27, 2010 12:18 pm Post subject: transfer function error/bug. |
|
|
Hello everyone,
I am creating some "generic" subroutines using transfer to move data between actual data type and an array of 1 byte characters.
I found that the use of the transfer function highlighted with a comment (***Error) in the following code doesn't work when I compile in CHECKMATE WIN32 mode, but works fine in DEBUG WIN32 mode.
I get a run time error that the character array is not defined when I run this in Plato. (In the FTN95 Express GUI it just crashes).
Is this a bug or am I missing something? Any help or information would be appreciated. I'm using Version 5.4 of FTN95 (as 5.5 doesn't seem to be available for download yet).
Code: |
module increments
type Composite
integer :: i
real :: r
end type Composite
contains
subroutine incrementComposite(data)
character(len=1),intent(inout) :: data(:)
type(Composite) :: b
b = transfer(data, b)
b%r = b%r + 1.0
b%i = b%i + 1
print *, b%r, b%i
data = transfer(b,data) ! ***Error here when in CHECKMATE mode
end subroutine incrementComposite
subroutine incrementTenTimes(func, data)
character(len=1) :: data(:)
interface
subroutine func(data)
character(len=1),intent(inout) :: data(:)
end subroutine func
end interface
integer :: i
do i=1,10
call func(data)
end do
end subroutine incrementTenTimes
end module increments
program anon
use increments
type(Composite) :: b
character(len=1), allocatable :: data(:)
integer :: lengthData
b%i = 0
b%r = 0.0
lengthData = size(transfer(b,data))
allocate(data(lengthData))
data = transfer(b,data)
call incrementTenTimes(incrementComposite,data)
b = transfer(data,b)
deallocate(data)
pause
end program anon |
|
|
Back to top |
|
|
silverfrost Site Admin
Joined: 29 Nov 2006 Posts: 191 Location: Manchester
|
Posted: Mon Jun 28, 2010 11:09 pm Post subject: |
|
|
Personal Edition 5.5 has been available for some time. Supported customers have had version 5.50 available from the release date. |
|
Back to top |
|
|
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Tue Jun 29, 2010 7:48 am Post subject: |
|
|
The latest FTN95 Express download only includes 5.4. (This is what I have).
I see from the KB you can install FTN95 Personal (to get 5.5) and then install only the IDE part of FTN95 Express. I will try that.
Will this fix the problem though? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Mon Jul 12, 2010 4:40 pm Post subject: |
|
|
I am not sure what is going on here.
The effect is apparent in version 5.5.
I will aim to investigate when I can find time. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Wed Jul 21, 2010 3:58 pm Post subject: |
|
|
Although this is technically a bug it is one of those that does not warrant a fix.
/checkmate (i.e. /full_undef) includes a check for undefined character values and these appear as Z'80'. FTN95 has applied this check before calling the transfer function and has found such a value.
The check is probably not warranted in this case but it does not seem reasonable to avoid this very special situation in the compiler code.
As a user you should use no more than /undef and not /full_undef in this local context. i.e. do not test for undefined character variables within this particular routine. |
|
Back to top |
|
|
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Thu Jul 29, 2010 12:17 am Post subject: |
|
|
Thanks Paul.
Sorry, I have not visited for a while and missed your posts but I'm very interested in your view.
Are you saying that you can't assume that you won't get hex 80 bytes in your data so /CHECKMATE will sometimes return false positives? Does this apply to all variable types or just character arrays?
If so its just a limitation of the method and can't be fixed without a total re-write of the compiler.
I was able to get the code above working by using an integer array as the "buffer" instead of a character array. However, I realised the concept was not really a good idea (too difficult to understand) and I have abandoned it now.
David. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Thu Jul 29, 2010 7:15 am Post subject: |
|
|
In fact I ended up by fixing this "bug" in the compiler although is is a very special case.
The reality is that the compiler has to use some value to represent the undefined state for each of the standard Fortran types. This means that, in general use, there will be very rare "random" events that cause the undefined checking to hit this undefined state. It is not surprising therefore that the transfer function is not really a candidate for applying this check.
Anyway, as I say, I have fixed this for the next release so everything should be OK in the present case. |
|
Back to top |
|
|
|