[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #11 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-10-16 10:52 --- Subject: Re: ICE in operand_subword_force, at emit-rtl.c:1353 franke dot daniel at gmail dot com [EMAIL PROTECTED] wrote on Sat, 14 Oct 2006: Don't know whether it makes any difference - but if it is the array constructor that crashes because of unequal string lengths within its arguments, why is there no problem with this code? PROGRAM test_constructor CHARACTER(len=32), DIMENSION(1,2) :: a a = reshape((/ one arg, another arg /), (/ 1, 2 /)) END PROGRAM Because this doesn't trigger the buggy codepath :-) Sometime in the past someone went to some lengths to support this kind of invalid code. Had they read the standard closely, they could have saved themselves some work. (Also compare with #3) I don't see the relation. Cheers, - Tobi This message was sent using IMP, the Internet Messaging Program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #10 from franke dot daniel at gmail dot com 2006-10-14 08:46 --- Don't know whether it makes any difference - but if it is the array constructor that crashes because of unequal string lengths within its arguments, why is there no problem with this code? PROGRAM test_constructor CHARACTER(len=32), DIMENSION(1,2) :: a a = reshape((/ one arg, another arg /), (/ 1, 2 /)) END PROGRAM (Also compare with #3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #8 from franke dot daniel at gmail dot com 2006-10-13 15:54 --- As requested in comment #7, a testcase for equal string lengths (identical to original PR but to_string() returns CHARACTER(len=255) instead of CHARACTER(len=32)): $ cat cat pr29267.f90 PROGRAM test_ice CHARACTER(len=255), DIMENSION(1,2) :: a a = reshape((/ x, to_string(1.0) /), (/ 1, 2 /)) CONTAINS CHARACTER(len=255) FUNCTION to_string(x) REAL, INTENT(in) :: x WRITE(to_string, FMT=(F6.3)) x END FUNCTION END PROGRAM $ gfortran-4.2 -g -Wall pr29267.f90 pr29267.f90: In function 'MAIN__': pr29267.f90:3: internal compiler error: in operand_subword_force, at emit-rtl.c:1353 $ gfortran-4.2 -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=$mylocalprefix --enable-bootstrap --enable-threads=posix --enable-shared --with-system-zlib --enable-languages=c,fortran --disable-nls --program-suffix=-4.2 Thread model: posix gcc version 4.2.0 20061013 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-10-13 19:19 --- Subject: Re: ICE in operand_subword_force, at emit-rtl.c:1353 franke dot daniel at gmail dot com [EMAIL PROTECTED] wrote on Fri, 13 Oct 2006: As requested in comment #7, a testcase for equal string lengths (identical to original PR but to_string() returns CHARACTER(len=255) instead of CHARACTER(len=32)): Oh, that's what you meant with equal lengths :-) This is indeed not required by the standard. And indeed, this triggers the same bug: the ICE has nothing to do with the assignment, it is the code dealing with the array constructor that is making us ICE. Thanks! This message was sent using IMP, the Internet Messaging Program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #7 from tobi at gcc dot gnu dot org 2006-10-09 11:14 --- (In reply to comment #6) please try the testcase in the orignal PR with idental string lengths. It will crash gfortran as well. Works for me. Please provide a testcase. [EMAIL PROTECTED]:~/src/pr/29267 cat t.f90 ! implicit character*32 (b-z) CHARACTER(len=255), DIMENSION(2) :: a a = reshape((/ 12345678901234567890123456789012, to_string(1.0) /), shape(a)) print *, a CONTAINS CHARACTER(32) FUNCTION to_string(x) REAL, INTENT(in) :: x WRITE(to_string, FMT=(F6.3)) x END FUNCTION END PROGRAM [EMAIL PROTECTED]:~/src/pr/29267 ~/src/gcc/build/gcc/f951 t.f90 MAIN__ to_string Execution times (seconds) parser: 0.01 (100%) usr 0.00 ( 0%) sys 0.01 (100%) wall 132 kB (18%) ggc TOTAL : 0.01 0.00 0.01 740 kB Extra diagnostic checks enabled; compiler may run slowly. Configure with --disable-checking to disable checks. [EMAIL PROTECTED]:~/src/pr/29267 so, why is an equivalent assignment through the array constructor invalid? Because the standard says so, I already quoted the relevant part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #6 from franke dot daniel at gmail dot com 2006-10-07 07:09 --- Tobi, Actually this is invalid code. The string lengths in the constructor are different, even though they have to be the same. please try the testcase in the orignal PR with idental string lengths. It will crash gfortran as well. OTOH, a(1,1) = x a(1,2) = to_string(1.0) should work even if CHARACTER(len=255), DIMENSION(1,2) :: a and CHARACTER(len=32) FUNCTION to_string(x), so, why is an equivalent assignment through the array constructor invalid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #3 from tobi at gcc dot gnu dot org 2006-10-06 20:36 --- Slightly reduced testcase, gives the same ice: implicit character*32 (a-z) CHARACTER(len=255), DIMENSION(1,2) :: a a = reshape((/ x, to_string(1.0) /), (/ 1, 2 /)) END PROGRAM -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #4 from tobi at gcc dot gnu dot org 2006-10-06 20:37 --- Another interesting variation: [EMAIL PROTECTED]:~/src/pr/29267 cat t.f90 implicit character*32 (a-z) CHARACTER(len=255), DIMENSION(1,2) :: a a = reshape((/ to_string(1.0) /), (/ 1, 2 /)) END PROGRAM [EMAIL PROTECTED]:~/src/pr/29267 ~/src/gcc/build/gcc/f951 t.f90 MAIN__ t.f90:1: fatal error: gfc_todo: Not Implemented: complex character array constructors compilation terminated. [EMAIL PROTECTED]:~/src/pr/29267 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #5 from tobi at gcc dot gnu dot org 2006-10-06 21:01 --- Actually this is invalid code. The string lengths in the constructor are different, even though they have to be the same. See 4.5 in the F95 standard. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-04 06:59:59 |2006-10-06 21:42:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-04 06:59 --- I think this code is valid. Changing to ice-on-valid-code. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i686-pc-linux-gnu | Keywords|ice-on-invalid-code |ice-on-valid-code Last reconfirmed|2006-09-28 13:09:57 |2006-10-04 06:59:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-28 13:09 --- Confirmed. (gdb) bt #0 fancy_abort ( file=0xc80d78 /space/rguenther/src/svn/trunk/gcc/emit-rtl.c, line=1353, function=0xc80ef0 operand_subword_force) at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:642 #1 0x0061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0, mode=QImode) at /space/rguenther/src/svn/trunk/gcc/emit-rtl.c:1353 #2 0x006351a6 in store_bit_field (str_rtx=0x2b22e2375ba0, bitsize=256, bitnum=0, fieldmode=QImode, value=0x2b22e2362f40) at /space/rguenther/src/svn/trunk/gcc/expmed.c:582 #3 0x0065441b in store_field (target=0x2b22e2375ba0, bitsize=256, bitpos=0, mode=BLKmode, exp=0x2b22e23639a0, type=0x2b22e2359d10, alias_set=0) at /space/rguenther/src/svn/trunk/gcc/expr.c:5591 #4 0x0064d0e2 in expand_assignment (to=0x2b22e235a300, from=0x2b22e23639a0) at /space/rguenther/src/svn/trunk/gcc/expr.c:4141 #5 0x0066d9cf in expand_expr_real_1 (exp=0x2b22e235b870, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /space/rguenther/src/svn/trunk/gcc/expr.c:8603 #6 0x0065a675 in expand_expr_real (exp=0x2b22e235b870, target=0x2b22e2284400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /space/rguenther/src/svn/trunk/gcc/expr.c:6700 (gdb) up #1 0x0061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0, mode=QImode) at /space/rguenther/src/svn/trunk/gcc/emit-rtl.c:1353 1353 gcc_assert (result); (gdb) list 1348 else 1349op = force_reg (mode, op); 1350} 1351 1352 result = operand_subword (op, offset, 1, mode); 1353 gcc_assert (result); 1354 1355 return result; 1356} 1357^L We're asking for a QImode subword at offset 0 of (mem/s/j:BLK (plus:DI (reg:DI 112) (reg:DI 96 [ D.1297 ])) [0 S32 A8]) in expansion of (*D.1297)[S.20D.1298] = D.1302 4.0 fails differently: gcc40-g/gcc ./f951 -quiet ../../gcc41-g/gcc/t.f90 ../../gcc41-g/gcc/t.f90: In function 'MAIN__': ../../gcc41-g/gcc/t.f90:8: internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2006-09-28 13:09:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
