 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
 Posted: Wed Mar 19, 2014 2:42 am Post subject: Use of TRANSFER |
 |
|
I have been testing the use of TRANSFER to be more standard conforming, but found a difference in the way TRANSFER works.
| Code: | integer*4, parameter :: sp = selected_real_kind (p=6)
real(sp) :: x
integer*4 i(4),j
!
i = (/ 1,2,3,4 /)
!
write (*,*) 'test for real kind =',sp, kind(1.0), kind(1.0d0)
x = 1
i(1) = transfer (x,j)
write (*,*) '1 ', x, i
!
x = tiny(x)
i(1:2) = transfer (x,j,2) ! 8 bytes requested but only 4 available
write (*,*) 'tiny', x, i
!
x = x/2
i(1:2) = transfer (x,j,2) ! 8 bytes requested but only 4 available
write (*,*) 'x/2 ', x, i
!
end |
While the result of the last 2 are requested as length 2(8 bytes), x (real*4) is only 4 bytes so the last 4 bytes are not provided.
FTN95 moves the first 4 bytes of i to the last 4 bytes, while other compilers set these last 4 bytes to zero.
Is this a case of the standard not defining the result for the last 4 bytes or should FTN95 not shift the bytes in this way, but set them to 0 ?
It could be a coding mistake, requesting 8 bytes when only 4 are available ?
John |
|
| Back to top |
|
 |
davidb
Joined: 17 Jul 2009
Posts: 560
Location: UK
|
| Posted: Wed Mar 19, 2014 7:46 am Post subject: |
|
|
In such cases, only the first 4 bytes are transferred. The second 4 bytes are undefined and can be set to arbitrary bit pattern by the compiler. Your code is OK provided you don't subsequently reference the second 4 bytes.
Most other compilers do seem to set the second 4 bytes to zero, which they are at liberty to do of course. However, the Lahey compiler sets them to the "undefined pattern" when this is enabled on the command line.
Silverfrost has a quirk here that it seems to shift the initial contents of the destination by 4 bytes before it does the transfer. This is allowed by the Standard, but is possibly unintended.
It would be nice if the Silverfrost compiler could set these undefined bytes to zero, except where UNDEF or CHECKMATE options are used, where it should set them to the undefined pattern.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Last edited by davidb on Wed Mar 19, 2014 8:11 am; edited 1 time in total |
|
| Back to top |
|
|
davidb
Joined: 17 Jul 2009
Posts: 560
Location: UK
|
| Posted: Wed Mar 19, 2014 8:09 am Post subject: |
|
|
Strange, this simpler example behaves much better when CHECKMATE is used.
| Code: |
integer :: dest(4), source, mold=0
dest = (/ 1,2,3,4 /)
source = 1
dest(1:2) = transfer (source, mold, 2) ! 8 bytes requested but only 4 available
write (*,*) dest ! Result should be 1, arbitrary, 3, 4
end
|
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Wed Mar 19, 2014 9:28 am Post subject: |
|
|
| I don't know if this is relevant but the /FULL_UNDEF part of /CHECKMATE will initialise all variables to an "undefined" state. |
|
| 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
