$ cat > gugu.f c AtAMul: Left-multiplies matrix AMat by its transpose ---------------- c AtAMat = transpose(AMat) * AMat c k,k k,n n,k c the resultant matrix AtAMat is returned in lower triangle form c --------------------------------------------------------------------- Subroutine AtAmul(AMat,AtAMat,kDim,nDim) IMPLICIT NONE c Input: Output: Local: Integer kDim,nDim, i, j, ij, n Real*8 AMat(kDim,nDim), AtAMat(kDim*(kDim+1)/2), Ai1, Ain c initialization loop n=1 : ij = 0 do i = 1, kDim Ai1 = AMat(i,1) do j = 1, i-1 AtAMat(ij+j) = Ai1 * AMat(j,1) enddo ij = ij + i AtAMat(ij) = Ai1 * Ai1 enddo c accumulation loop n=2,nDim : do n = 2, nDim ij = 0 do i = 1, kDim Ain = AMat(i,n) do j = 1, i-1 AtAMat(ij+j) = AtAMat(ij+j) + Ain * AMat(j,n) enddo ij = ij + i AtAMat(ij) = AtAMat(ij) + Ain * Ain enddo enddo end gfortran -O3 -ftree-loop-linear gugu.f gugu.f: In function 'atamul_': gugu.f:6:0: internal compiler error: in initialize_matrix_A, at tree-data-ref.c:1912 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. $ gfortran-4.4 -O3 -ftree-loop-linear gugu.f gugu.f: In function 'atamul': gugu.f:6: internal compiler error: in initialize_matrix_A, at tree-data-ref.c:1880 Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions. $ gfortran-4.3 -O3 -ftree-loop-linear gugu.f /usr/lib/gcc/i486-linux-gnu/4.3.4/libgfortranbegin.a(fmain.o): In function `main': (.text+0x35): undefined reference to `MAIN__' collect2: ld returned 1 exit status
This is most likely related to PR 40281.
Fails on x86-64-linux with gfortran -m32 -O1 -ftree-loop-linear but works with -m64.
First reported by Hans Horn at http://gcc.gnu.org/ml/fortran/2009-11/msg00084.html
Indeed. Same symptoms at least: (gdb) call debug_generic_expr (chrec) {0, +, {2, +, 1}_4}_4 This one fails for me with -m32 only though. The chrec isn't quite {2, +, 1}_4 - I think the IV evolves as 0, 3, 4, 5, 6, ... if I parse it correctly. That looks more like a loop like for (i=0;; ++i) for (j=i+3;; ++j) ... where we somehow cleverly analyze this as a single loop... (?). Sebastian - please have a look here and/or at PR40281. *** This bug has been marked as a duplicate of 40281 ***