[Bug fortran/32393] gfortran - incorrect run time results

["dominiq at lps dot ens dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #27 from dominiq at lps dot ens dot fr  2007-06-24 10:51 -------
> As Dominique, I still get an error for "g95 -O2", but that is a different
> compiler (usually found with GCC 4.0.x backend; note GCC < 4.1.x is no longer
> maintained.)

Note that g95 can be compiled with 4.1:

Using built-in specs.
Target: 
Configured with: ../configure
--prefix=/sw/lib/gcc-lib/powerpc-apple-darwin7/4.1.2 --enable-languages=c
--with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld
--with-nm=/sw/lib/odcctools/bin/nm --with-included-gettext
Thread model: posix
gcc version 4.1.2 (g95 0.91!) Jun 24 2007

which gives the expected result. So it seems that the problem is a bug in
gcc4.0 (besides the conformity to f2003 that I am not sure to really
understand).

Caveat:

(1)  when compiled with 4.1, g95 gives ICE on derived type I/O when compiled
with -O (at least on Mac OSX 10.3.9):

! Related to PR 19928.  Check that foo() is only called once per statement.
! { dg-do run }
program main
  implicit none
  type t
    integer, dimension (5) :: field
  end type t
  type (t), dimension (2) :: a
  integer :: calls, i, j

  forall (i = 1:2, j = 1:5) a(i)%field(j) = i * 100 + j
  print *, a
end program main

[karma] bug/ice_g95_4.1% g95 -O type_1_red.f90
type_1_red.f90:3: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.g95.org or mail andyv@firstinter.net for instructions.

(2) I have an infinite loop with the following code and -O3:

! { dg-do run }
! Program to check corner cases for DO statements.
program do_1
  implicit none
  integer i, j, k

  ! Bound near smallest value
  j = 0;
  print *, -HUGE(i)
  k = -HUGE(i)
  do i = -HUGE(i), -HUGE(i)
!  do i = -HUGE(i)+3, -HUGE(i)+3, 4
!  do i = -HUGE(i)+9, -HUGE(i)+9, 10
!  do i = k, k, 10
    j = j + 1
  end do
  print *, j
  if (j .ne. 1) call abort
end program

A long time ago, I have reported the problem to Andy who is blaming the gcc
middle-end, so if someone working in this area have an idea ...!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393