[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-08-26 02:13 --- Subject: Bug 41859 Author: jvdelisle Date: Thu Aug 26 02:12:49 2010 New Revision: 163561 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163561 Log: 2010-08-25 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/41859 * gfortran.dg/der_io_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/der_io_4.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-08-19 02:36 --- Subject: Bug 41859 Author: jvdelisle Date: Thu Aug 19 02:35:45 2010 New Revision: 163363 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163363 Log: 2010-08-19 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41859 * resolve.c (resolve_transfer): Traverse operands and set expression to be checked to a non EXPR_OP type. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-08-19 04:01 --- Closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-08-16 06:09 --- The problem resides in resolve_transfer. The checks are not performed because the expression is wrapped in parenthesis and so the expression is of type EXPR_OP, so resolve_transfer is just exited. The following patch simply finds the first operand that is not of type EXPR_OP and sets exp to that for checking. Index: resolve.c === --- resolve.c (revision 163259) +++ resolve.c (working copy) @@ -7696,6 +7696,12 @@ exp = code-expr1; + while (exp != NULL exp-expr_type == EXPR_OP) +exp = exp-value.op.op1; + + if (exp == NULL) +return; + if (exp-expr_type != EXPR_VARIABLE exp-expr_type != EXPR_FUNCTION) return; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #7 from dominiq at lps dot ens dot fr 2010-08-07 17:07 --- I was getting back to this and noticed that we no longer ICE on the original test case. ... Still gives an ICE on x86_64-apple-darwin10.4.0 revision 162979. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #8 from dominiq at lps dot ens dot fr 2010-08-07 18:31 --- With trunk the ICE is a Segmentation fault and the backtrace is #0 0x0001417aee0b in __gmpz_sub () #1 0x0001000e1c8f in transfer_array_component (expr=0x141f04300, cm=0x141915170, where=0x141915ca8) at ../../work/gcc/fortran/trans-io.c:1933 #2 0x0001000e20c9 in transfer_expr (se=0x7fff5fbfd450, ts=value temporarily unavailable, due to optimizations, addr_expr=value temporarily unavailable, due to optimizations, code=0x141915c90) at ../../work/gcc/fortran/trans-io.c:2094 #3 0x0001000e6346 in gfc_trans_transfer (code=value temporarily unavailable, due to optimizations) at ../../work/gcc/fortran/trans-io.c:2230 #4 0x0001000a87d8 in trans_code (code=0x141915c90, cond=0x1418453b8) at ../../work/gcc/fortran/trans.c:1281 #5 0x0001000e409f in build_dt (function=0x141ef1a00, code=0x141915ed0) at ../../work/gcc/fortran/trans-io.c:1800 #6 0x0001000a8818 in trans_code (code=0x141915ed0, cond=0x0) at ../../work/gcc/fortran/trans.c:1253 #7 0x0001000c6ca2 in gfc_generate_function_code (ns=value temporarily unavailable, due to optimizations) at ../../work/gcc/fortran/trans-decl.c:4495 #8 0x0001000a9103 in gfc_generate_module_code (ns=value temporarily unavailable, due to optimizations) at ../../work/gcc/fortran/trans.c:1412 #9 0x00010006af31 in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4395 #10 0x0001000a3abc in gfc_be_parse_file (set_yydebug=value temporarily unavailable, due to optimizations) at ../../work/gcc/fortran/f95-lang.c:241 #11 0x0001006924da in toplev_main (argc=2, argv=0x7fff5fbfd9d8) at ../../work/gcc/toplev.c:971 #12 0x00010c84 in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-07-23 12:28 --- I was getting back to this and noticed that we no longer ICE on the original test case. I suppose then this has become an accepts invalid or there is something not being initialized and the behavior is random. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 21:17 --- If print *, (foo()) is changed to print *, foo() one gets: $ gfortran-svn pr41859.f90 pr41859.f90:17.19: print *, foo() ! -- ICE here! 1 Error: Data transfer element at (1) cannot have POINTER components Same for the second problem: $ gfortran-svn pr41859-c1.f90 pr41859-c1.f90:37.19: print *, foo() ! 1 Error: Data transfer element at (1) cannot have PRIVATE components -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 21:17:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 21:30 ---
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
7370return;
7371
(gdb) print *exp
$2 = {expr_type = EXPR_OP, ts = {type = BT_DERIVED, kind = 0, u = {derived =
0x8bc7ad8, cl = 0x8bc7ad8}, interface = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_UNKNOWN},
rank = 0, shape = 0x0, symtree = 0x0, ref = 0x0, where = {nextc = 0x8bfa9ec,
lb = 0x8bfa9b0}, inline_noncopying_intrinsic = 0, is_boz = 0, is_snan = 0,
error = 0,
user_operator = 0, representation = {length = 0, string = 0x0}, value =
{logical = 27, iokind = 27, integer = {{_mp_alloc = 27, _mp_size = 0, _mp_d =
0x8bb1450}}, real = {{
_mpfr_prec = 27, _mpfr_sign = 0, _mpfr_exp = 146478160, _mpfr_d =
0x0}}, complex = {{re = {{_mpfr_prec = 27, _mpfr_sign = 0, _mpfr_exp =
146478160, _mpfr_d = 0x0}}, im = {
{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0, op
= {op = INTRINSIC_PARENTHESES, uop = 0x0, op1 = 0x8bb1450, op2 = 0x0}, function
= {actual = 0x1b,
name = 0x0, isym = 0x8bb1450, esym = 0x0}, compcall = {actual = 0x1b,
name = 0x0, base_object = 0x8bb1450, tbp = 0x0, ignore_pass = 0, assign = 0},
character = {
length = 27, string = 0x0}, constructor = 0x1b}}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 21:54 ---
Comment #3 is somewhat hard to parse. Once more with this reduced testcase:
TYPE :: ptype
character, pointer, dimension(:) :: x = null()
END TYPE
TYPE(ptype) :: p
print *, (p)! '()' are significant
end
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
7370return;
7371
(gdb) p exp-expr_type
$11 = EXPR_OP
(gdb) p exp-ts.u.derived-name
$12 = 0xb7f47a08 ptype
(gdb) p exp-value.op
$13 = {op = INTRINSIC_PARENTHESES, uop = 0x0, op1 = 0x8bb1450, op2 = 0x0}
(gdb) p exp-value.op.op1-expr_type
$14 = EXPR_VARIABLE
(gdb) p exp-value.op.op1-ts.u.derived-name
$15 = 0xb7f47a08 ptype
No idea how to fix this, adding the obvious check and workaround for EXPR_OP
feels wrong. More likely, EXPR_OP should never have been passed down here?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-05-19 05:47 --- I have a patch testing. -- 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|2010-05-18 21:17:52 |2010-05-19 05:47:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-28 22:32 --- If a list item of derived type in an unformatted input/output statement is not processed by a user-defined derived-type input/output procedure (9.5.3.7), and if any subobject of that list item would be processed by a user-defined derived-type input/output procedure, the list item is treated as if all of the components of the object were specified in the list in component order (4.5.3.5); those components shall be accessible in the scoping unit containing the input/output statement and shall not be pointers or allocatable. If a list item of derived type in a formatted input/output statement is not processed by a user-defined derived-type input/output procedure, that list item is treated as if all of the components of the list item were specified in the list in component order; those components shall be accessible in the scoping unit containing the input/output statement and shall not be pointers or allocatable. If a derived-type list item is not treated as a list of its individual components, that list items ultimate components shall not have the POINTER or ALLOCATABLE attribute unless that list item is processed by a user-defined derived-type input/output procedure. (F2003, 9.5.2). * * * Note: The scope issue is also violated as the following example shows. Other compilers get this right: error #7300: This derived-type object in an input-output list cannot have private components. Error: Data transfer element at (1) cannot have PRIVATE components Error: Derived type T in io-list has PRIVATE components module inputdom type t PRIVATE ! integer :: i end type t end module module m use inputdom contains subroutine getstructinput() implicit none print *, (foo()) ! end subroutine function foo() type(t), pointer :: foo foo = null() end function foo end module m -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
