New: ICE in operand_subword_force, at emit-rtl.c:1353
12 answers - 792 bytes -

$cat ice.f90
PRGRAM test_ice
CHARACTER(len=255), DIMENSIN(1,2) :: a
a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /))
CNTAINS
CHARACTER(32) FUNCTIN to_string(x)
REAL, INTENT(in) :: x
WRITE(to_string, FMT="(F6.3)") x
END FUNCTIN
END PRGRAM
$gfortran-4.2 -g -Wall ice.f90
ice.f90: In function ‘MAIN__’:
ice.f90:3: internal compiler error: in operand_subword_force, at
emit-rtl.c:1353
Please submit a full bug report,
$gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /gcc/configure
/
,c++,fortran
Thread model: posix
gcc version 4.2.0 20060914 (experimental)
Initially reported here:
(the testcase above is a reduced version of that posted to the ML)
No.1 | | 1929 bytes |
| 
Comment #1 from rguenth at gcc dot gnu dot org 2006-09-28 13:09
Confirmed.
(gdb) bt
#0 fancy_abort (
file=0xc80d78 "/", line=1353,
function=0xc80ef0 "operand_subword_force")
at /
#1 0x000000000061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0,
mode=QImode) at /
#2 0x00000000006351a6 in store_bit_field (str_rtx=0x2b22e2375ba0,
bitsize=256, bitnum=0, fieldmode=QImode, value=0x2b22e2362f40)
at /
#3 0x000000000065441b in store_field (target=0x2b22e2375ba0, bitsize=256,
bitpos=0, mode=BLKmode, exp=0x2b22e23639a0, type=0x2b22e2359d10,
alias_set=0) at /
#4 0x000000000064d0e2 in expand_assignment (to=0x2b22e235a300,
from=0x2b22e23639a0) at /
#5 0x000000000066d9cf in expand_expr_real_1 (exp=0x2b22e235b870, target=0x0,
tmode=VIDmode, modifier=EXPAND_NRMAL, alt_rtl=0x0)
at /
#6 0x000000000065a675 in expand_expr_real (exp=0x2b22e235b870,
target=0x2b22e2284400, tmode=VIDmode, modifier=EXPAND_NRMAL, alt_rtl=0x0)
at /
(gdb) up
#1 0x000000000061cc08 in operand_subword_force (op=0x2b22e2375be0, offset=0,
mode=QImode) at /
1353 gcc_assert (result);
(gdb) list
1348 else
1349 op = 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 <for instructions.
No.2 | | 128 bytes |
| 
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.
No.3 | | 255 bytes |
| 
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), DIMENSIN(1,2) :: a
a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /))
END PRGRAM
No.4 | | 505 bytes |
| 
Comment #4 from tobi at gcc dot gnu dot org 2006-10-06 20:37
Another interesting variation:
schluter@pcl247:~/src/pr/29267cat t.f90
implicit character*32 (a-z)
CHARACTER(len=255), DIMENSIN(1,2) :: a
a = reshape((/ to_string(1.0) /), (/ 1, 2 /))
END PRGRAM
schluter@pcl247:~/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.
schluter@pcl247:~/src/pr/29267
No.5 | | 218 bytes |
| 
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.
No.6 | | 282 bytes |
| 
--
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| |
No.7 | | 565 bytes |
| 
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.
TH,
a(1,1) = "x"
a(1,2) = to_string(1.0)
should work even if
CHARACTER(len=255), DIMENSIN(1,2) :: a
and
CHARACTER(len=32) FUNCTIN to_string(x),
so, why is an equivalent assignment through the array constructor invalid?
No.8 | | 1097 bytes |
| 
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.
schluter@pcl247:~/src/pr/29267cat t.f90
! implicit character*32 (b-z)
CHARACTER(len=255), DIMENSIN(2) :: a
a = reshape((/ "", to_string(1.0) /),
shape(a))
print *, a
CNTAINS
CHARACTER(32) FUNCTIN to_string(x)
REAL, INTENT(in) :: x
WRITE(to_string, FMT="(F6.3)") x
END FUNCTIN
END PRGRAM
schluter@pcl247:~/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
TTAL : 0.01 0.00 0.01
740 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with to disable checks.
schluter@pcl247:~/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.
No.9 | | 932 bytes |
| 
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
PRGRAM test_ice
CHARACTER(len=255), DIMENSIN(1,2) :: a
a = reshape((/ "x", to_string(1.0) /), (/ 1, 2 /))
CNTAINS
CHARACTER(len=255) FUNCTIN to_string(x)
REAL, INTENT(in) :: x
WRITE(to_string, FMT="(F6.3)") x
END FUNCTIN
END PRGRAM
$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 $mylocalprefix
,fortran
Thread model: posix
gcc version 4.2.0 20061013 (experimental)
No.10 | | 808 bytes |
| 
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 <gcc-bugzilla (AT) gcc (DOT) gnu.orgwrote on
Fri, 13 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)):
, 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.
No.11 | | 449 bytes |
| 
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?
PRGRAM test_constructor
CHARACTER(len=32), DIMENSIN(1,2) :: a
a = reshape((/ "one arg", "another arg" /), (/ 1, 2 /))
END PRGRAM
(Also compare with #3)
No.12 | | 1022 bytes |
| 
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 <gcc-bugzilla (AT) gcc (DOT) gnu.orgwrote on
Sat, 14 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?
PRGRAM test_constructor
CHARACTER(len=32), DIMENSIN(1,2) :: a
a = reshape((/ "one arg", "another arg" /), (/ 1, 2 /))
END PRGRAM
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.