| View previous topic :: View next topic |
| Author |
Message |
mecej4
Joined: 31 Oct 2006
Posts: 1899
|
 Posted: Sat Mar 13, 2010 10:44 am Post subject: Compiler V 5.30 bug |
 |
|
The following extract shows a compiler bug encountered with a much larger program. The bug is related to the use of vector subscripts.
The bug goes away if 4-byte integers are used instead of 2-byte integers.
| Code: |
program bugsal
implicit none
integer, parameter :: short = selected_int_kind(4)
integer(SHORT), parameter :: NIW=70
INTEGER(SHORT),DIMENSION(NIW) :: IW
IW(2)=0
IW(3)=0
IW(22)=69
call SUB(NIW,IW)
stop
end program bugsal
SUBROUTINE SUB(NIW, IW)
IMPLICIT NONE
integer, parameter :: short = selected_int_kind(4)
INTEGER(SHORT), intent(in) :: NIW
INTEGER(SHORT), intent(in) :: IW(NIW)
INTEGER(SHORT) :: JW(2)
INTEGER(SHORT) :: IOIB
IOIB=1
JW=2+IW(IOIB+1:IOIB+2)+20
write(*,'(1x,2I8)')JW ! JW is [22,22]
JW=IW(JW) ! causes crash with read access violation
! should have become [69,69]
write(*,'(1x,2I8)')JW
RETURN
END SUBROUTINE SUB
|
|
|
| Back to top |
|
 |
sparge
Joined: 11 Apr 2005
Posts: 371
|
| Posted: Sat Mar 13, 2010 12:22 pm Post subject: |
|
|
| I just tried with v5.40 and the crash still happens. I've never used vector subscripts so I don't know if the offending statement is legit or not - it's not something I would be comfortable with doing even if it is ... |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Sun Mar 14, 2010 1:08 pm Post subject: |
|
|
I'd call the following line of code a bug.
| Code: | JW=IW(JW) ! causes crash with read access violation
|
However, the following would be legal
| Code: |
IOIB = 22
JW = IW(IOIB)
|
|
|
| Back to top |
|
|
sparge
Joined: 11 Apr 2005
Posts: 371
|
| Posted: Sun Mar 14, 2010 1:44 pm Post subject: Re: |
|
|
| JohnCampbell wrote: | I'd call the following line of code a bug.
| Code: | JW=IW(JW) ! causes crash with read access violation
|
|
Can you clarify what you mean by this, John? Do you mean the line of code is illegal, and the bug is that the compiler does not pick it up, or do you mean that the code is legal and the bug is that the compiler crashes? You seem to imply a compiler bug either way.
| JohnCampbell wrote: | However, the following would be legal
| Code: |
IOIB = 22
JW = IW(IOIB)
|
|
Based on this, I am assuming you mean the first of the two alternatives. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Mon Mar 15, 2010 1:57 am Post subject: |
|
|
Sorry,
I don't think that "IW(JW)" is legal fortran. I'm not aware of being able to use an array to define an array section, although I could be wrong.
It is interesting to use an integer array to index an array section, although I'd probably put that in a DO loop.
It can be a challenge to see what you can put in a single line, but perhaps not good programing style.
John |
|
| Back to top |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1899
|
| Posted: Mon Mar 15, 2010 2:23 am Post subject: RE: vector subscripts |
|
|
Vector subscripts are legal in Fortran 90 and beyond. See, for example, article 2.10 of Metcalf and Reid, "Fortran 95/2003 Explained", OUP.
FTN95 compiles and gives correct results when full-word (32-bit) are used instead of SHORTS.
As to style: vector expressions allow compact implementation of algorithms. Packages such as Matlab and Octave are built around that idea. Many Fortran-77 to Fortran 9x translators are capable of producing, at the user's option, vector expressions in the output. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Mon Mar 15, 2010 4:00 am Post subject: |
|
|
You're right. I checked my fortran 95 references and they even have an example.
Oh the joys of being a compiler writer !
I write a lot of code in Fortran, but have never seen the need for such a construct. I don't think I would use it either, as I don't think it would be easy to see when coded.
Looks like another of those C coding techniques that have been introduced that can result in programming bugs that are too hard to see. Unfortunately there have been too many C programmers writing the Fortran standard and not enough pragmatic Fortran programmers who know the benefit of simple structures that assist in writing bug free programs. I've always used the KISS principle and accomplished a considerable amount (on time) with that approach.
John |
|
| Back to top |
|
|
sparge
Joined: 11 Apr 2005
Posts: 371
|
| Posted: Mon Mar 15, 2010 9:32 am Post subject: Re: RE: vector subscripts |
|
|
| mecej4 wrote: | | FTN95 compiles and gives correct results when full-word (32-bit) are used instead of SHORTS. |
I'm with John on this - my instinctive reaction to the line of code was "Eeeek!". Even now I know it's legal, I still wouldn't be tempted.
So it's a compiler bug. Until it's fixed, and based on the result with SHORTs, I would be worrying about the possibility of unidentified collateral damage when 32-bit integers are used. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Mon Mar 15, 2010 1:36 pm Post subject: |
|
|
| In can confirm that this is a compiler bug and that I have logged it for investigation. |
|
| Back to top |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1899
|
| Posted: Thu Mar 18, 2010 2:28 am Post subject: Re: |
|
|
| PaulLaidler wrote: | | In can confirm that this is a compiler bug and that I have logged it for investigation. |
Thank you.
This bug aside, FTN95 has been very helpful in locating and fixing bugs resulting from porting a 1980-s Fortran-77 program, intended to run on a 8086 in 128 kB, to Fortran 90 on a modern platform. |
|
| Back to top |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1899
|
| Posted: Thu Mar 18, 2010 2:40 am Post subject: Re: RE: vector subscripts |
|
|
| sparge wrote: | | mecej4 wrote: | | FTN95 compiles and gives correct results when full-word (32-bit) are used instead of SHORTS. |
I'm with John on this - my instinctive reaction to the line of code was "Eeeek!". Even now I know it's legal, I still wouldn't be tempted.
So it's a compiler bug. Until it's fixed, and based on the result with SHORTs, I would be worrying about the possibility of unidentified collateral damage when 32-bit integers are used. |
The original program (over 11,000 lines) was written by a distinguished scientist in the 1980s, for the 8086. The program is amazing in that it provides an efficient solution to a very complex problem (chemical equilibrium). To fit the program into the 8086 "compact model" ( 64K code+64K data ) he made liberal use of EQUIVALENCE, which makes the code hard to understand.
I have ported it from Fortran 77 to Fortran 90. Fortunately, there are a number of test cases with known results, and the ported code runs fine whether 16 bit integers or 32 bit integers are used.
In situations such as these, correctness and efficiency take precedence over style. Secondly, popularity in style varies with time, and it would be no more appropriate for me to comment on the original author's style than for a scouser to criticise Shakespeare's English. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2615
Location: Sydney
|
| Posted: Thu Mar 18, 2010 8:27 am Post subject: |
|
|
The offending line | Code: | JW=IW(JW) ! causes crash with read access violation
|
was not legal fortran in 1980's. The use of array syntax was introduced in F90 and then enhanced in F95.
Fortran 90 & 95 did standardise a lot of syntax that was extended by most fortran 77 compiler providers.
There were a lot of memory saving tricks that were not standard but tollerated by most F77 compiler implementations. You're lucky the distinguished scientist did not also use overlays to increase memory available to the program.
When converting other programmers F77 code, you hope they did not break too many rules. You may also want to look up compiler options /do1 and /zero for pre F90 compatibility.
John |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8210
Location: Salford, UK
|
| Posted: Sat Aug 21, 2010 6:39 am Post subject: |
|
|
| This bug has now been fixed for the next release. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
