User account creation filtered due to spam.

Bug 34946 - [4.3 Regression] internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592
Summary: [4.3 Regression] internal compiler error: in gfc_trans_create_temp_array, at ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P4 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 32834 29975
  Show dependency treegraph
 
Reported: 2008-01-23 19:24 UTC by Joost VandeVondele
Modified: 2008-01-26 19:13 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.2.3
Known to fail:
Last reconfirmed: 2008-01-24 19:41:48


Attachments
testcase (2.53 KB, text/plain)
2008-01-23 19:25 UTC, Joost VandeVondele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joost VandeVondele 2008-01-23 19:24:44 UTC
GNU Fortran (GCC) 4.3.0 20080121 (experimental) [trunk revision 131689] yields

> gfortran -ffree-form bug.F
bug.F: In function ‘rs_grid_create’:
bug.F:147: internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Comment 1 Joost VandeVondele 2008-01-23 19:25:12 UTC
Created attachment 15010 [details]
testcase
Comment 2 Richard Biener 2008-01-23 21:46:31 UTC
Fortran is not release-critical.
Comment 3 Joost VandeVondele 2008-01-24 07:27:27 UTC
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
Comment 4 Joost VandeVondele 2008-01-24 08:08:09 UTC
and also confirmed for the latest gfortran:

gcc version 4.3.0 20080124 (experimental) [trunk revision 131776] 
Comment 5 Richard Biener 2008-01-24 11:06:32 UTC
Confirmed.
Comment 6 Paul Thomas 2008-01-24 15:12:35 UTC
Joost,

When did this last work?

Paul
Comment 7 Joost VandeVondele 2008-01-24 15:22:00 UTC
(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.
Comment 8 Dominique d'Humieres 2008-01-24 15:41:22 UTC
> When did this last work?

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

Comment 9 Paul Thomas 2008-01-24 15:55:48 UTC
(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

Comment 10 Dominique d'Humieres 2008-01-24 16:00:59 UTC
> 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

Comment 11 Joost VandeVondele 2008-01-24 16:05:45 UTC
> 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


Comment 12 Daniel Franke 2008-01-24 19:24:42 UTC
For another ICE at trans-array.c:592 see example at PR31610, comment #12.
Comment 13 Paul Thomas 2008-01-24 19:41:47 UTC
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

Comment 14 Tobias Burnus 2008-01-25 08:52:52 UTC
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.
Comment 15 Joost VandeVondele 2008-01-25 19:10:47 UTC
(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



Comment 16 Jerry DeLisle 2008-01-26 02:39:15 UTC
See comment #15 of pr31610 for some interesting results on this.
Comment 17 Jerry DeLisle 2008-01-26 04:42:17 UTC
Probable patch posted in 31610
Comment 18 Paul Thomas 2008-01-26 11:58:27 UTC
(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
Comment 19 Jerry DeLisle 2008-01-26 19:13:48 UTC
Fixed, see PR 31610