[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- 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
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- 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
--- 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
--- 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
--- 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 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 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- 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
--- 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 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
--- 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
--- 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
--- 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
-- 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
--- 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
--- 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 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
--- 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
--- 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
--- 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
--- 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 isDATA 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
--- 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
--- 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
--- 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|-00-00 00:00:00 |2005-11-21 21:02:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
