- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear,
Here is a small Fortran program to reproduce the reason of my question:
```fortran
program test
use iso_fortran_env, only: int32, int16
implicit none
integer(int32), parameter :: m1 = int(z'776BF593', int32)
integer(int16), parameter :: m116(2) = transfer( m1, 0_int16, 2 )
print*, 'Should ', transfer(m116, 0_int32), ' be equal to ', m1, '?'
write(*,'(b32.32)') m1
write(*,'(2(b16.16))') m116
end program
```
Based on the Intel documentation of the intrinsic `transfer` that mentions "...Otherwise, the result contains the bit pattern contained in source
Is the application of `transfer` on this last bit processor-dependent, as `m1` and `m116` are `integer`?
In advance thank you.
* OS: Fedora 34
* Compiler: ifort (IFORT) 2021.4.0 20210910
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your report. This issue has been escalated to compiler engineering.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FWIW on my machine M116 differs from m1 in more than the first bit. The two elements of m116 have the same value [-2669,-2669] while gfortran gives [-2669, 30571]. It appears that m116(2) = transfer( m1, 0_int16, 2 ), instead of transferring all 32 bits to m116, is just replicating the first 16 bits twice. For transfer, I would expect something similar to a C type cast of a 32 bit integer to a pair of overlaid 16 bit integers, which is what I get from gfortran.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Following the meassage of @wclodius , I had a closer look, and indeed, more than 1 bit changed.
Here are the result for ifort 2021.4.0:
```
m116 -2669 -2669
-174852717 should be equal to 2003563923 ?
01110111011010111111010110010011
11110101100100111111010110010011
```
I can reproduce this behaviour with `ifx 2021.4.0` and `ifort 17.0.0`
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This seems to be a bug when `transfer` is used with `parameter`, because when used without `parameter`, the back-transfer returns the original result.
```
program test
use iso_fortran_env, only: int32, int16
implicit none
integer(int32), parameter :: m1 = int(z'776BF593', int32)
integer(int16), parameter :: m116(2) = transfer( m1, 0_int16, 2 )
integer(int16) :: m216(2)
print*,'m116 ',m116
m216 = transfer( m1, 0_int16, 2 )
print*,'m216 ',m216
print*,transfer(m116, 0_int32), ' should be equal to ', m1,'?'
print*,transfer(m216, 0_int32), ' should be equal to ', m1,'?'
write(*,'(b32.32)')m1
write(*,'(2(b16.16))')m116
write(*,'(2(b16.16))')m216
end program
```
output:
```
m116 -2669 -2669
m216 -2669 30571
-174852717 should be equal to 2003563923 ?
2003563923 should be equal to 2003563923 ?
01110111011010111111010110010011
11110101100100111111010110010011
11110101100100110111011101101011
```
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your report. This issue has been escalated to compiler engineering.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page