Created attachment 15010 [details]
testcase

Fortran is not release-critical.

reduced testcase:

MODULE test
  TYPE realspace_grid_input_type
     INTEGER       :: distribution_layout(3)
  END TYPE realspace_grid_input_type
  TYPE realspace_grid_type
     INTEGER, DIMENSION (3) :: npts                      ! # grid points per dimension
     INTEGER :: group_size
  END TYPE realspace_grid_type
CONTAINS
  SUBROUTINE rs_grid_create ( rs, input_settings )
    TYPE(realspace_grid_type), POINTER       :: rs
    TYPE(realspace_grid_input_type), &
      INTENT(IN)                             :: input_settings
    INTEGER                                  :: n_slices_tmp(3)
             IF (.NOT. ALL(PACK(n_slices_tmp==input_settings % distribution_layout,&
                                (/-1,-1,-1/)/=input_settings % distribution_layout )&
                          )) STOP
  END SUBROUTINE rs_grid_create
END MODULE

and also confirmed for the latest gfortran:

gcc version 4.3.0 20080124 (experimental) [trunk revision 131776] 

Confirmed.

Joost,

When did this last work?

Paul

(In reply to comment #6)
> When did this last work?

unfortunately I don't know. This piece of code might actually be newer than my latest test of gfortran on CVS CP2K.

> When did this last work?

The reduced test case is compiled by 4.2.2, but not by 4.3.0 20071125 (experimental).

(In reply to comment #8)
> > When did this last work?
> The reduced test case is compiled by 4.2.2, but not by 4.3.0 20071125
> (experimental).

Dominique,

What is the date on the 4.2.2?

Paul

> What is the date on the 4.2.2?

From gcc.gnu.org:pub/gcc/releases, I'ld guess 2007 Oct  8:

drwxrwsr-x   3 ftp      ftp          4096 Oct  8 22:07 gcc-4.2.2

> What is the date on the 4.2.2?
the relevant data might be the branching of 4.2
       +-- GCC 4.2 branch created ------+
       |            (Oct 20 2006)        \
       v                                  v

For another ICE at trans-array.c:592 see example at PR31610, comment #12.

I'm getting there...

Something is going wrong in setting the loop start value (as is obvious from the gcc_assert:)) that is fixed by interchanging the order of expressions in the mask.

Thusly:

input_settings%distribution_layout/=(/-1,-1,-1/)

I suggest this as a workaround, whilst I figure out who in trans-array.c is failing to make the right choice of subexpression.

Paul

The change seems to be introduced around 2007-01-08-r120570 / 2007-01-09-r120610.

Most probably:

r120584 | sayle | 2007-01-08 18:56:37 +0100 (Mo, 08 Jan 2007) | 19 lines

        * trans-array.c (constant_array_constructor_p): New function to
        determine whether an array constructor consists only of constant
        elements, and if so return it's size.
        (gfc_build_constant_array_constructor): Construct a statically
        initialized gfortran array for a given EXPR_ARRAY.
        (gfc_trans_constant_array_constructor): Efficiently scalarize
        a constant array constructor.
        (gfc_trans_array_constructor):  Tidy up use of CONST_STRING.
        Special case scalarization of constant array constructors, all of
        whose elements are specified, using constant_array_constructor_p
        and gfc_trans_constant_array_constructor.
        (gfc_conv_scalarized_array_ref): Check whetger info->offset is zero
        before adding it to index, to avoid creating a NON_LVALUE_EXPR.

        * gfortran.dg/array_constructor_14.f90: New test case.
        * gfortran.dg/vect/vect-5.f90: Update test for improved alignment.

(In reply to comment #12)
> For another ICE at trans-array.c:592 see example at PR31610, comment #12.

yes, it is almost certainly the same problem:

  integer :: i(1) = 0
  write(*,*) foo(i+[1])
end

compiles while

  integer :: i(1) = 0
  write(*,*) foo([1]+i)
end

ICEs

See comment #15 of pr31610 for some interesting results on this.

Probable patch posted in 31610

(In reply to comment #17)
> Probable patch posted in 31610
> 
See my remark there -> if we can understand it, I would feel reassured but, if not, lets go with your version of the patch and keep this PR open as an "error-recovery" (there does not appear to be a "dunno-whats-going-on" key word:) ) bug.

Paul

Fixed, see PR 31610