- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems that CSHIFT intrinsic function has a bug
when at least one of the array bounds is zero or less.
The following program shows this weird behaviour:
####################################################
####################################################
Follows the output:
####################################################
System informations:
Intel Fortran Compiler for 32-bit applications, Version 9.0 Build 20051201Z
ID: l_fc_c_9.0.031
Slackware GNU/Linux 10.2
glibc 2.3.6
kernel 2.4.32
Mobile Intel Pentium 4 - M CPU 2.00GHz
The above test program gives the correct results
with g95 (gcc version 4.0.1 Jan 9 2006) on the
same platform, and with Sun Fortran 95 8.0 on
Solaris 8 (ULTRASPARC 9):
Is this really a bug?
Thanks,
P. Fogli
when at least one of the array bounds is zero or less.
The following program shows this weird behaviour:
####################################################
PROGRAM test_cshift
IMPLICIT NONE
! Allocatable array later allocated with negative bounds
INTEGER, ALLOCATABLE :: pa(:)
! Array with lower bound = 0
INTEGER :: ps(0:4) = (/ 1, 2, 3, 4, 5 /)
INTEGER :: k=1
WRITE(*,*) 'k: ', k
WRITE(*,*) 'ps: ', ps
ps=CSHIFT(ps,k)
WRITE(*,*) 'ps: ', ps
ALLOCATE(pa(-31:-29))
pa = (/ 10, 11, 12 /)
WRITE(*,*) 'pa: ', pa
pa=CSHIFT(pa,k)
WRITE(*,*) 'pa: ', pa
DEALLOCATE(pa)
STOP
END PROGRAM test_cshift
####################################################
Follows the output:
$> ifort -o test test_cshift.f90
$> ./test
k: 1
ps: 1 2 3 4 5
ps: 3 4 5 0 2
pa: 10 11 12
pa: 0 0 0
####################################################
System informations:
Intel Fortran Compiler for 32-bit applications, Version 9.0 Build 20051201Z
ID: l_fc_c_9.0.031
Slackware GNU/Linux 10.2
glibc 2.3.6
kernel 2.4.32
Mobile Intel Pentium 4 - M CPU 2.00GHz
The above test program gives the correct results
with g95 (gcc version 4.0.1 Jan 9 2006) on the
same platform, and with Sun Fortran 95 8.0 on
Solaris 8 (ULTRASPARC 9):
$> g95 -o test test_cshift.f90
$> ./test
k: 1
ps: 1 2 3 4 5
ps: 2 3 4 5 1
pa: 10 11 12
pa: 11 12 10
#> f90 -o test test_cshift.f90
#> ./test
k: 1
ps: 1 2 3 4 5
ps: 2 3 4 5 1
pa: 10 11 12
pa: 11 12 10
Is this really a bug?
Thanks,
P. Fogli
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see the same bad result with ifort 9.0.028 on SuSE 9.2 32-bit, while 9.1.017 produces the correct result.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is 9.1 already released?
The web page still report version 9.0
(9.0.031 on the ftp).
I feel that version 8.1 too has this bug
but I can't test it myself because
I no longer have that version.
BTW, if version 9.1 has fixed the bug a preprocessor conditional like the following one should be sufficient:
The web page still report version 9.0
(9.0.031 on the ftp).
I feel that version 8.1 too has this bug
but I can't test it myself because
I no longer have that version.
BTW, if version 9.1 has fixed the bug a preprocessor conditional like the following one should be sufficient:
#if defined(__INTEL_COMPILER) && (__INTEL_COMPILER <= 900)
! work around code
#else
! normal code
#endif
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Wait for l_fc_c_9.0.032, should be available in the next few days. The bug is fixed in that version.
9.1 is still in beta.
9.1 is still in beta.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page