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.

            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

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 ...

I'd call the following line of code a bug.

      JW=IW(JW)                        ! causes crash with read access violation 

However, the following would be legal

      IOIB = 22
      JW = IW(IOIB)

Quoted from JohnCampbell I'd call the following line of code a bug.

      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.

Quoted from JohnCampbell However, the following would be legal

      IOIB = 22
      JW = IW(IOIB)

Based on this, I am assuming you mean the first of the two alternatives.

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

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.

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

Quoted from mecej4 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.

In can confirm that this is a compiler bug and that I have logged it for investigation.

Quoted from PaulLaidler In can confirm that this is a compiler bug and that I have logged it for investigation. [u:b956ab049e]

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.[/u:b956ab049e]

Quoted from sparge

Quoted from mecej4 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.

The offending line 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

This bug has now been fixed for the next release.