reduced from CP2K (PR 29975) gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu gcc version 4.3.0 20070531 (experimental) gfortran -fprefetch-loop-arrays -O2 test.f90 test.f90: In function ‘polint’: test.f90:1: internal compiler error: tree check: expected integer_cst, have plus_expr in int_cst_value, at tree.c:7720 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. SUBROUTINE polint(xa,ya,n,x,y,dy) INTEGER, PARAMETER :: dp=KIND(0.0D0) INTEGER, INTENT(in) :: n REAL(dp), INTENT(in) :: ya(n), xa(n), x REAL(dp), INTENT(out) :: y, dy INTEGER :: i, m, ns REAL(dp) :: c(n), d(n), den, dif, dift, & ho, hp, w ! ! ns=1 dif=ABS(x-xa(1)) DO i = 1,n dift=ABS(x-xa(i)) IF (dift.lt.dif) THEN ns=i dif=dift ENDIF c(i)=ya(i) d(i)=ya(i) END DO ! y=ya(ns) ns=ns-1 DO m = 1,n-1 DO i = 1,n-m ho=xa(i)-x hp=xa(i+m)-x w=c(i+1)-d(i) den=ho-hp IF(den.eq.0.) STOP 'POLINT' den=w/den d(i)=hp*den c(i)=ho*den END DO IF (2*ns.lt.n-m)THEN dy=c(ns+1) ELSE dy=d(ns) ns=ns-1 ENDIF y=y+dy END DO ! RETURN END SUBROUTINE polint
While the assert is occurs in the middle end, I think it is very likely a tree-type mismatch in the front end.
reduced: SUBROUTINE polint(n) INTEGER, PARAMETER :: dp=KIND(0.0D0) REAL(dp) :: ya(n), xa(n), x DO m = 1,n-1 DO i = 1,n-m ho=xa(i)-x hp=xa(i+m)-x den=ho-hp IF(den.eq.0.) STOP 'POLINT' END DO END DO END SUBROUTINE polint
#2 0x0000000000a30ddc in int_cst_value (x=0x2b8d9ea73780) at /space/rguenther/src/svn/trunk/gcc/tree.c:7720 7720 unsigned HOST_WIDE_INT val = TREE_INT_CST_LOW (x); (gdb) call debug_generic_expr (x) (int8) {2, +, 1}_1 + -1 this is a problem in data-ref analysis. 1761 if (TREE_CODE (chrec) != POLYNOMIAL_CHREC) 1762 return int_cst_value (chrec); I guess Zdenek exposed this somehow.
Compilation works for me with: gcc-Version 4.3.0 20070607 x86_64-unknown-linux-gnu
(In reply to comment #4) > Compilation works for me with: > gcc-Version 4.3.0 20070607 x86_64-unknown-linux-gnu > still failing for me with a compiler a few minutes old: vondele@pcihopt1:~/g95> cat /scratch/vondele/gcc_trunk/gcc/LAST_UPDATED Thu Jun 7 10:12:05 CEST 2007 Thu Jun 7 08:12:05 UTC 2007 (revision 125521) vondele@pcihopt1:~/g95> gfortran -fprefetch-loop-arrays -O2 test.f90 test.f90: In function ‘polint’: test.f90:1: internal compiler error: tree check: expected integer_cst, have plus_expr in int_cst_value, at tree.c:7720 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. vondele@pcihopt1:~/g95> gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /scratch/vondele/gcc_trunk/gcc/configure --prefix=/scratch/vondele/gcc_trunk/build --with-mpfr_include=/scratch/vondele/mpfr-2.2.0/ --with-mpfr_lib=/scratch/vondele/mpfr-2.2.0/ --with-gmp=/users/vondele/ --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070607 (experimental)
(In reply to comment #1) > While the assert is occurs in the middle end, I think it is very likely a > tree-type mismatch in the front end. I think it is. It also fails for me on i686-darwin, with -O2 -fprefetch-loop-arrays -m64.
There is a cast which confuses SCEV.
I can reproduce this 4.3 regression with the following C testcase: $ cat w.c void foo (void) { int i, m; float xa[21]; m = 0; while (1) { i = 0; while (1) { if (xa[(long int)i] == xa[(long int)(i+m)]) _gfortran_abort (); if (i == 10) break; i++; } if (m == 10) break; m++; } } $ gcc -O2 -fprefetch-loop-arrays -m64 w.c w.c: In function ‘foo’: w.c:2: internal compiler error: tree check: expected integer_cst, have nop_expr in int_cst_value, at tree.c:7720
I cannot reproduce this on x86_64 with any of the testcases.
(In reply to comment #9) > I cannot reproduce this on x86_64 with any of the testcases. Looks like this bug has 'fixed' itself somewhere during the last two weeks ... can't reproduce it either
(In reply to comment #10) > (In reply to comment #9) > > I cannot reproduce this on x86_64 with any of the testcases. > > Looks like this bug has 'fixed' itself somewhere during the last two weeks ... > can't reproduce it either Please commit the testcase (that failed at some time) to the testsuite and close this bug.
Subject: Bug 32176 Author: uros Date: Tue Jul 3 06:35:05 2007 New Revision: 126245 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126245 Log: PR middle-end/32176 * gcc.dg/pr32176.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr32176.c Modified: trunk/gcc/testsuite/ChangeLog
Closed as magically fixed (testcase was committed to SVN mainline).