[Bug regression/24978] New: ICE in gfc_assign_data_value_range

[Bug regression/24978] New: ICE in gfc_assign_data_value_range

[uttamp at us dot ibm dot com]

Following code is causing the internal compiler error.

$ cat test.f90
       real            :: a(5,5)
       data a/25*1.0/
       data a(1,1), a(3,1), a(1,2), a(3,3) /2*1.0, 2*2.0/
       data a(2:5,4) /4*1.0/
       end

$ gfortran test.f90
t38.f90:0: internal compiler error: in gfc_assign_data_value_range, at
fortran/data.c:423
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

$ gfortran -v
Using built-in specs.
Target: powerpc64-linux
Configured with: /home/gccbuild/gcc_trunk_anonsvn/trunk/configure
--prefix=/opt/gcc-nightly/trunk-20051117 --build=powerpc64-linux
--host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32
--with-as=/opt/gcc-nightly/trunk-20051117/bin/as
--with-ld=/opt/gcc-nightly/trunk-20051117/bin/ld --enable-threads=posix
--enable-shared --enable-__cxa_atexit
--enable-languages=c,c++,f95,java,objc,obj-c++ --enable-checking
--with-mpfr=/opt/gcc-nightly/trunk-20051117
Thread model: posix
gcc version 4.1.0 20051117 (experimental)


-- 
           Summary: ICE in gfc_assign_data_value_range
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: regression
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: uttamp at us dot ibm dot com
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-21 21:02 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|                            |4.0.2 4.1.0
   Last reconfirmed|0000-00-00 00:00:00         |2005-11-21 21:02:12
               date|                            |


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dje at gcc dot gnu dot org]

------- Comment #2 from dje at gcc dot gnu dot org  2006-01-03 16:27 -------
Not powerpc-specific.


-- 

dje at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|powerpc64-linux             |
   GCC host triplet|powerpc64-linux             |
 GCC target triplet|powerpc64-linux             |


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[fxcoudert at gcc dot gnu dot org]

------- Comment #3 from fxcoudert at gcc dot gnu dot org  2006-06-04 10:01 -------
I marked it as ice-on-valid-code, but I'm not sure it's valid code. g95 emits
an error, but Intel and Sun compilers don't. Uttam, do you know if that code is
valid?


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|2005-11-21 21:02:12         |2006-06-04 10:01:03
               date|                            |


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2006-06-05 17:40 -------
(In reply to comment #3)
> I marked it as ice-on-valid-code, but I'm not sure it's valid code. g95 emits
> an error, but Intel and Sun compilers don't. Uttam, do you know if that code is
> valid?
> 

It is invalid-code.

5.2.10     DATA statement

R532  data-stmt     is    DATA data-stmt-set [ [ , ] data-stmt-set ] ...

This statement is used to specify explicit initialization (504).
A variable, or part of a variable, shall not be explicitly initialized more
than once in a program.  If a nonpointer object or subobject has been
specified with default initialization in a type definition, it shall not
appear in a data-stmt-object-list.

I've changed this to ice-on-invalid-code


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu dot org
           Keywords|ice-on-valid-code           |ice-on-invalid-code


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2006-10-29 05:16 -------
Should we simply avoid the ice, perhaps accepting the invalid code or do we
want to search for duplicates in the DATA statements and generate an error?

Also,

Is this valid?:

real :: a(5,5)
DATA a(1,1), a(3,1), a(1,2), a(3,3) /2*1.0, 2*2.0/
DATA a(2,1) /2.5/

In other words, no overlap in the DATA statements.  It is a big difference if
we have to search element by element.  I suspect this is why this is not a
constraint on the compiler, but is a restriction on the programmer, so to
speak.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[jvdelisle at gcc dot gnu dot org]

------- Comment #6 from jvdelisle at gcc dot gnu dot org  2006-10-29 16:47 -------
I have started looking into this one


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-06-04 10:01:03         |2006-10-29 16:47:07
               date|                            |


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #7 from sgk at troutmask dot apl dot washington dot edu  2006-10-29 20:02 -------
Subject: Re:  ICE in gfc_assign_data_value_range

> Should we simply avoid the ice, perhaps accepting the invalid code or do we
> want to search for duplicates in the DATA statements and generate an error?
> 
> Also,
> 
> Is this valid?:
> 
> real :: a(5,5)
> DATA a(1,1), a(3,1), a(1,2), a(3,3) /2*1.0, 2*2.0/
> DATA a(2,1) /2.5/
> 
> In other words, no overlap in the DATA statements.  It is a big difference if
> we have to search element by element.  I suspect this is why this is not a
> constraint on the compiler, but is a restriction on the programmer, so to
> speak.
> 

NAG compiles the following code:

  real :: a(5,5)
  DATA a(1,1), a(3,1), a(1,2), a(3,3) /2*1.0, 2*2.0/
  DATA a(2,1) /2.5/
  print *, a(1,1), a(3,1), a(1,2), a(3,3), a(2,1)
  end program

and gives the expected output.  If a(2,1) is changed to a(3,3),
then NAG generates

laptop:kargl[209] f95 -o z t.f90
Error: t.f90, line 3: Element no. 13 of object A already initialised
Errors in declarations, no further processing for $main$
[f95 error termination]


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[jvdelisle at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]



------- Comment #8 from jvdelisle at gcc dot gnu dot org  2006-10-29 23:51 -------
Here is a case that makes it through gfortran and into middle-end or back-end.

real :: a(5,5)
DATA a /25*-5.0/ !(1,1), a(3,1), a(1,2), a(3,3) /2*1.0, 2*2.0/
DATA a(2,1) /2.5/
print '(5f5.2)', a
end

test2.f90: In function ‘MAIN__’:
test2.f90:1: internal compiler error: in output_constructor, at varasm.c:4318
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

So obvously we need to catch this.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[pault at gcc dot gnu dot org]

------- Comment #9 from pault at gcc dot gnu dot org  2006-10-30 21:34 -------
Steve and Jerry,

> laptop:kargl[209] f95 -o z t.f90
> Error: t.f90, line 3: Element no. 13 of object A already initialised
> Errors in declarations, no further processing for $main$
> [f95 error termination]
> 
 The standard is very specific that no variable or element thereof should be
intialized more than once.  I cannot give you chapter and verse right now but I
looked at this PR once and decided that the time was not quite right.

Jerry, dependency.c has a lot of code for checking the overlap between array
references; you could maybe use/hijack some of it.

Paul


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2006-12-10 14:29 -------
> > Error: t.f90, line 3: Element no. 13 of object A already initialised
>
>  The standard is very specific that no variable or element thereof should be
> intialized more than once.  I cannot give you chapter and verse right now but 
> looked at this PR once and decided that the time was not quite right.

In Fortran 2003 it is in 5.1 (look for the paragraph with the bold-printed
"explicit initialization."):

"Explicit initialization alternatively may be specified in a DATA statement
unless the variable is of a derived type for which default initialization is
specified. If initialization is =initialization-expr , the object-name is
initially defined with the value specified by the initialization-expr ; if
necessary, the value is converted according to the rules of intrinsic
assignment
29 (7.4.1.3) to a value that agrees in type, type parameters, and shape with
the object-name. A variable, or part of a variable, shall not be explicitly
initialized more than once in a program."


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[jvdelisle at gcc dot gnu dot org]

-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #11 from dfranke at gcc dot gnu dot org  2007-12-19 00:53 -------
Having a look ...


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org
         AssignedTo|unassigned at gcc dot gnu   |dfranke at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
      Known to fail|4.0.2 4.1.0                 |4.0.2 4.1.2 4.3.0
   Last reconfirmed|2006-10-29 16:47:07         |2007-12-19 00:53:59
               date|                            |


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #12 from dfranke at gcc dot gnu dot org  2007-12-21 17:40 -------
Getting rid of the ICEs does not seem to be too difficult. Unfortunately, 
internal reworking seems to be necessary to actually solve every aspect of this
PR.

I will attach two sets of testcases; a list of valid DATA-statements and a list
of invalid ones. Neither list claims to be exhaustive, however, they might be
useful for anyone going to tackle this.

Some notes:
 * the invalid testcases sport at least three different ICEs, two asserts in
   data.c (gfc_assign_data_value,gfc_assign_data_value_range) and one deep
   down (middle-end/back-end?) in varasm.c. I assume that the latter one will
   go away as soon as the splay-tree look ups are fixed for all the testcases,
   no additional investigation necessary.
 * DATA statements are handled in inverse ordering to their specification. For
   me it helped a lot to get them in native ordering, i.e. by declaration.
 * resolve.c (resolve_data_variables) states: "[...] data lists should
   only be resolved once." -- they seem to be resolved twice. To be seen in
     integer :: b(3)
     data       b(-2) / 1 /
     end
   where the out-of-bounds warning is printed twice.
 * out-of-bounds checks need to be errors for DATA-statements

Unassigning myself.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #13 from dfranke at gcc dot gnu dot org  2007-12-21 17:41 -------
Created an attachment (id=14804)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14804&action=view)
set of valid testcases


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #14 from dfranke at gcc dot gnu dot org  2007-12-21 17:41 -------
Created an attachment (id=14805)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14805&action=view)
set of invalid testcases


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|dfranke at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[bdavis at gcc dot gnu dot org]

------- Comment #15 from bdavis at gcc dot gnu dot org  2007-12-23 03:07 -------
the test cases are great...but they show too many bugs !!  can't decide whether
to go for the 'grand unified solution' or just hit them one at a time :)


--bud


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[riccardo dot scorretti at univ-lyon1 dot fr]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]



------- Comment #16 from riccardo dot scorretti at univ-lyon1 dot fr  2008-05-13 12:42 -------
Hi! I think I'm experiencing a similar bug: the source code is:

program test_vecteurs
  implicit none

  integer :: n
  integer, dimension(0:9) :: x = (/ (n, n=1,10,2), (0,n=1,5) /)

  data (x(n), n=0,9) / 10*0 /
  x = (/ (n, n=1,10,2), (0, n=1,5) /)
  do n = 0, 9
    print *, "x(", n, ") = ", x(n)
  end do
end program



>> gfortran -v -save-temps f3.f95 -o f3
Driving: gfortran -v -save-temps f3.f95 -o f3 -lgfortranbegin -lgfortran -lm
-shared-libgcc
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
 /usr/lib/gcc/x86_64-linux-gnu/4.2.3/f951 f3.f95 -quiet -dumpbase f3.f95
-mtune=generic -auxbase f3 -version -fstack-protector -I
/usr/lib/gcc/x86_64-linux-gnu/4.2.3/finclude -o f3.s
GNU F95 version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) (x86_64-linux-gnu)
        compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f3.f95: In function ‘MAIN__’:
f3.f95:1: internal compiler error: in output_constructor, at varasm.c:4308
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-4.2/README.Bugs>.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #17 from dfranke at gcc dot gnu dot org  2008-06-23 09:53 -------
*** Bug 36604 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu dot org


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[jvdelisle at gcc dot gnu dot org]

------- Comment #18 from jvdelisle at gcc dot gnu dot org  2009-12-01 03:01 -------
As an update, gfortran currently passes the data-valid.f90 test and ices on the
data-invalid.f90 case.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[jvdelisle at gcc dot gnu dot org]

------- Comment #19 from jvdelisle at gcc dot gnu dot org  2009-12-05 17:01 -------
Try this patch:

Index: data.c
===================================================================
--- data.c      (revision 155006)
+++ data.c      (working copy)
@@ -497,7 +497,13 @@ gfc_assign_data_value_range (gfc_expr *lvalue, gfc
              expr->expr_type = EXPR_ARRAY;
              expr->rank = ref->u.ar.as->rank;
            }
-         else
+         else if (expr->expr_type != EXPR_ARRAY)
+           {
+             gfc_error ("Duplicate initialization at %L",
+                        &expr->where);;
+             return;
+           }
+
            gcc_assert (expr->expr_type == EXPR_ARRAY);

          if (ref->u.ar.type == AR_ELEMENT)
@@ -558,8 +564,12 @@ gfc_assign_data_value_range (gfc_expr *lvalue, gfc
                   pred->next = con;
                }
            }
-         else
-           gcc_assert (ref->next != NULL);
+         else if (ref->next == NULL)
+           {
+             gfc_error ("Duplicate initialization at %L",
+                        &rvalue->where);;
+             return;
+           }
          break;

        case REF_COMPONENT:


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dominiq at lps dot ens dot fr]

------- Comment #20 from dominiq at lps dot ens dot fr  2009-12-06 14:56 -------
With the patch in comment #19, the test in comment #14 no longer gives ICEs. 

However I noticed that several invalid cases are not detected (a and b in
data_init_(scalar|array|matrix)_invalid, and c and d in
data_init_(array|matrix)_invalid). 

Only f and h in data_init_(array|matrix)_invalid. give the two occurrences for
the duplicates (after having changed the dimensions of h in
data_init_matrix_invalid).

When isolated, e in data_init_(array|matrix)_invalid and g
data_init_matrix_invalid give ICEs in output_constructor_regular_field, at
varasm.c:4773 (neither ICE nor error when there is another initialization
giving itself an error).

Finally i and j  in data_init_(array|matrix)_invalid triggered the second and
first ICE respectively.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dominiq at lps dot ens dot fr]

------- Comment #21 from dominiq at lps dot ens dot fr  2009-12-06 14:58 -------
Note that comment #20 confirms comment #12.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #22 from dfranke at gcc dot gnu dot org  2010-04-30 21:02 -------
Proposed patch:
    http://gcc.gnu.org/ml/fortran/2010-04/msg00328.html


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dominiq at lps dot ens dot fr]

------- Comment #23 from dominiq at lps dot ens dot fr  2010-05-01 09:57 -------
I have applied the patch in comment #22 and it fixes all the ICE I have in
store with DATA initialization (including those remaining after the patch in
comment #19: see comment #20).

I have also found that codes such as:

SUBROUTINE data_init_matrix_invalid()
  ! full array initializer, re-initialize full array
  integer :: i(3,3)
  data       i   / 3*1, 3*2, 3*3 /
  data       i   / 9 * 1 /
END SUBROUTINE
end

are only detected with the -pedantic option. This should probably documented in
http://gcc.gnu.org/onlinedocs/gfortran/Old_002dstyle-variable-initialization.html#Old_002dstyle-variable-initialization
.

Now there is something annoying: compiling the above code with -pedantic leads
to 9 times the same warning:

Warning: Extension: re-initialization of 'i' at (1)
pr24978_4_ma_i2.f90:5.24:

  data       i   / 9 * 1 /
                        1

This is a minor inconvenience for small values of the multiplier, but is a real
problem for large ones: if I replace 9 with 100, I get 100 warnings!-(
Would it be possible to get only one warning per multiplier?

Note that

SUBROUTINE data_init_array_invalid()
  ! full array initializer, re-initialize (at least) one element
  integer :: e(3)
  data       e    / 3*1 /
  data       e(2) / 2 /
END SUBROUTINE
end

gives only one warning.

A similar problem can be seen with codes such as:

SUBROUTINE data_init_matrix_invalid()
  ! full array initializer, re-initialize full array
  integer :: j(3) = 0
  data       j   / 9 * 1 /
END SUBROUTINE
end

which gives 3 errors (without option) for j:

pr24978_4_ma_i1.f90:4.6:

  data       j   / 9 * 1 /
      1
pr24978_4_ma_i1.f90:3.19:

  integer :: j(3) = 0
                   2
Error: 'j' at (1) already is initialized at (2)
pr24978_4_ma_i1.f90:4.6:

  data       j   / 9 * 1 /
      1
pr24978_4_ma_i1.f90:3.19:

  integer :: j(3) = 0
                   2
Error: 'j' at (1) already is initialized at (2)
pr24978_4_ma_i1.f90:4.6:

  data       j   / 9 * 1 /
      1
pr24978_4_ma_i1.f90:3.19:

  integer :: j(3) = 0
                   2
Error: 'j' at (1) already is initialized at (2)
pr24978_4_ma_i1.f90:4.6:

  data       j   / 9 * 1 /
      1
Error: DATA statement at (1) has more values than variables

Final note pr36604 is a duplicate of this pr.

Thanks for the patch.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #24 from dfranke at gcc dot gnu dot org  2010-05-01 10:24 -------
(In reply to comment #23)
> are only detected with the -pedantic option.

Or -std=f95; data.c has:
  /* Overwriting an existing initializer is non-standard but usually only
     provokes a warning from other compilers.  */
  [...]
  gfc_notify_std (GFC_STD_GNU, "Extension: re-initialization "
                  "of '%s' at %L", symbol->name, &expr->where);

-pedantic gives a warning, -std=f* an error.


> Now there is something annoying: compiling the above code with -pedantic leads
> to 9 times the same warning:

Since 9 values are consecutively overwritten - however, this can be fixed.


> SUBROUTINE data_init_array_invalid()
>   ! full array initializer, re-initialize (at least) one element
>   integer :: e(3)
>   data       e    / 3*1 /
>   data       e(2) / 2 /
> END SUBROUTINE
> end
> 
> gives only one warning.

Since only one value is overwritten, e(2) - e(1) and e(3) are initialized only
once.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #25 from dfranke at gcc dot gnu dot org  2010-05-01 10:36 -------
Dominique, if you apply this hunk

Index: data.c
===================================================================
--- data.c      (revision 158958)
+++ data.c      (working copy)
@@ -352,8 +352,10 @@ gfc_assign_data_value (gfc_expr *lvalue,
          expr = (LOCATION_LINE (init->where.lb->location)
                  > LOCATION_LINE (rvalue->where.lb->location))
               ? init : rvalue;
-         gfc_notify_std (GFC_STD_GNU, "Extension: re-initialization "
-                         "of '%s' at %L", symbol->name, &expr->where);
+         if (gfc_notify_std (GFC_STD_GNU,"Extension: "
+                             "re-initialization of '%s' at %L",
+                             symbol->name, &expr->where) == FAILURE)
+           return FAILURE;
        }

       expr = gfc_copy_expr (rvalue);


And modify the for-loop in gfc_assign_data_value_range() to match this ...

+  for (mpz_set(offset, index) ; mpz_cmp(offset, last_offset) < 0;
+                  mpz_add_ui (offset, offset, 1))
+    if (gfc_assign_data_value (lvalue, rvalue, offset) == FAILURE)
+      break;

then (most of) the duplicate warnings should be gone.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dominiq at lps dot ens dot fr]

------- Comment #26 from dominiq at lps dot ens dot fr  2010-05-01 12:20 -------
> Dominique, if you apply this hunk ...

With the changes in comment #25, I get only warnings/errors along one dimension
(probably the first, but have to check): a(3,3) gives 3 warnings/errors and
a(10,10) gives 10 of them.

> Or -std=f95; data.c has: ...

Yes, I realized that "extension" should mean errors with -std=f*!-)


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dominiq at lps dot ens dot fr]

------- Comment #27 from dominiq at lps dot ens dot fr  2010-05-01 12:30 -------
> With the changes in comment #25, I get only warnings/errors along one dimension
> (probably the first, but have to check)

Apparently the repetition is along the last dimension:
i(5,10) gives 10 errors/warnings and i(10,5) gives 5 ones.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #28 from dfranke at gcc dot gnu dot org  2010-05-01 12:36 -------
(In reply to comment #27)
> Apparently the repetition is along the last dimension:
> i(5,10) gives 10 errors/warnings and i(10,5) gives 5 ones.

Could you post the full test? I can't reproduce this?!


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dominiq at lps dot ens dot fr]

------- Comment #29 from dominiq at lps dot ens dot fr  2010-05-01 12:59 -------
>Could you post the full test? I can't reproduce this?!

[macbook] lin/test% cat ../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90
SUBROUTINE data_init_matrix_invalid()
  ! full array initializer, re-initialize full array
  integer :: i(5,10)
  data       i   / 5*1, 5*2, 5*3, 5*4, 5*5, 5*6, 5*7, 5*8, 5*9, 5*10 /
  data       i   / 50 * 1 /
END SUBROUTINE
end
[macbook] lin/test% gfc -std=f95
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
[macbook] lin/test% cat ../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_2.f90
SUBROUTINE data_init_matrix_invalid()
  ! full array initializer, re-initialize full array
  integer :: i(10,5)
  data       i   / 10*1, 10*2, 10*3, 10*4, 10*5 /
  data       i   / 50 * 1 /
END SUBROUTINE
end
[macbook] lin/test% gfc -std=f95
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_2.f90
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_2.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_2.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_2.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_2.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)
../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_2.f90:5.25:

  data       i   / 50 * 1 /
                         1
Error: Extension: re-initialization of 'i' at (1)


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #30 from dfranke at gcc dot gnu dot org  2010-05-01 13:13 -------
Created an attachment (id=20525)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20525&action=view)
updated patch

Updated patch. Fixes the multiplication of errors shown in comment #29. Not yet
regtested.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dominiq at lps dot ens dot fr]

------- Comment #31 from dominiq at lps dot ens dot fr  2010-05-02 08:52 -------
> Updated patch. Fixes the multiplication of errors shown in comment #29. Not yet
> regtested.

The patch in comment #30 fixes the multiplication of errors. The only
regression I have found is 

FAIL: gfortran.dg/spread_size_limit.f90  -O  scan-tree-dump-times original
"_gfortran_spread" 1

where the test should be updated/removed due to the change in simplify.c.

I cannot do a formal review, but the patch looks good. Thanks for it.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #32 from dfranke at gcc dot gnu dot org  2010-05-02 09:23 -------
(In reply to comment #31)
> FAIL: gfortran.dg/spread_size_limit.f90  -O  scan-tree-dump-times original
> "_gfortran_spread" 1
> where the test should be updated/removed due to the change in simplify.c.

That's a leftover from PR40472 - Jerry asked to leave the check for array size
in, so please revert that change in your tree. No more regressions :)


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dominiq at lps dot ens dot fr]

------- Comment #33 from dominiq at lps dot ens dot fr  2010-05-02 09:31 -------
> That's a leftover from PR40472 - Jerry asked to leave the check for array size
> in, so please revert that change in your tree. No more regressions :)

This change fixed an ICE for the test in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472#c21 , reverting it will
restore the ICE!-(I can either reopen pr40472 for it, or open a new pr, but not
before a couple days). In top of that I am not sure we are all speaking about
the same thing.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #34 from dfranke at gcc dot gnu dot org  2010-05-05 18:54 -------
Subject: Bug 24978

Author: dfranke
Date: Wed May  5 18:53:23 2010
New Revision: 159076

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159076
Log:
gcc/fortran/:
2010-05-05  Daniel Franke  <franke.daniel@gmail.com>

        PR fortran/24978
        * gfortran.h: Removed repeat count from constructor, removed
        all usages.
        * data.h (gfc_assign_data_value_range): Changed return value from
        void to gfc_try.
        * data.c (gfc_assign_data_value): Add location to constructor element.
        (gfc_assign_data_value_range): Call gfc_assign_data_value()
        for each element in range. Return early if an error was generated.
        * resolve.c (check_data_variable): Stop early if range assignment
        generated an error.

gcc/testsuite/:
2010-05-05  Daniel Franke  <franke.daniel@gmail.com>

        PR fortran/24978
        * gfortran.dg/data_invalid.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/data_invalid.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/array.c
    trunk/gcc/fortran/constructor.c
    trunk/gcc/fortran/data.c
    trunk/gcc/fortran/data.h
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #35 from dfranke at gcc dot gnu dot org  2010-05-05 19:03 -------
Fixed in trunk. No backport to 4.5 as the required constructor rework is not
ported either. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #36 from dfranke at gcc dot gnu dot org  2010-05-05 19:41 -------
(In reply to comment #35)
> Fixed in trunk. No backport to 4.5 as the required constructor rework is not
> ported either. Closing.

2nd try,


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[kargl at gcc dot gnu dot org]

------- Comment #37 from kargl at gcc dot gnu dot org  2010-05-17 21:46 -------
*** Bug 44177 has been marked as a duplicate of this bug. ***


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harry dot rockefeller at
                   |                            |flightsafety dot com


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

------- Comment #38 from dfranke at gcc dot gnu dot org  2010-06-01 20:53 -------
*** Bug 44351 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zeccav at gmail dot com


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