[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #29 from mikael at gcc dot gnu dot org 2009-01-05 20:10 --- (In reply to comment #28) I think this PR can be closed - the ICEs are gone, the TODO item is gone and the missing warnings are tracked in PR 33037. Closing then. It was probably fixed together with PR 37903. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #27 from pault at gcc dot gnu dot org 2008-11-15 15:20 --- As far as I can see, all the valid testcases work on trunk and 4.3 - should we close this one? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #28 from burnus at gcc dot gnu dot org 2008-11-15 18:41 --- I think this PR can be closed - the ICEs are gone, the TODO item is gone and the missing warnings are tracked in PR 33037. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #26 from jsm28 at gcc dot gnu dot org 2008-07-04 19:47 --- Leaving open for further investigation bug should not have milestone set. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #24 from jsm28 at gcc dot gnu dot org 2008-03-15 00:40 --- Update milestone after 4.3.0 release. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2008-01-26 19:11 --- Fixed on trunk. Leaving open for further investigation. See TODO comment in code -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|32834 | nThis|| AssignedTo|brooks at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to fail|4.3.0 | Summary|[4.3 Regression] ICE with |ICE with transfer, merge in |transfer, merge in |gfc_conv_expr_descriptor |gfc_conv_expr_descriptor| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-12-08 17:16 --- Brooks, are you still working this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-11-22 09:09
---
It's not even MERGE-related:
$ cat a.f90
integer :: i(1) = 0
write(*,*) foo([1]+i)
end
$ gfortran a.f90
a.f90: In function MAIN__:
a.f90:1: internal compiler error: in gfc_trans_create_temp_array, at
fortran/trans-array.c:592
The assertion in fails because the loop-from[0] is equal to 1, but we want it
to be zero. It is set to 1 in gfc_conv_loop_setup:
/* Set the extents of this range. */
cshape = loopspec[n]-shape;
if (cshape INTEGER_CST_P (info-start[n])
INTEGER_CST_P (info-stride[n]))
{
loop-from[n] = info-start[n];
mpz_set (i, cshape[n]);
mpz_sub_ui (i, i, 1);
/* To = from + (size - 1) * stride. */
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-11-12 00:18 --- Reduced further: $ cat m.f90 logical :: a(1) a = .true. write(*,*) foo(merge((/ 1 /), 1, a)) end $ gfortran m.f90 m.f90: In function MAIN__: m.f90:2: internal compiler error: in gfc_trans_create_temp_array, at fortran/trans-array.c:592 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #10 from burnus at gcc dot gnu dot org 2007-09-17 17:39 --- For the warning that TRANSFER contains partially undefined values, see also PR 33037. For MERGE, see PR 33455 Independent of those, the following valid program still gives an ICE (if one removes the 20 in transfer, the ICE is gone). Also the patch http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01953.html does not seem to help. character(len=20) :: string logical :: a(20) a = .true. write(*,*) transfer (merge (transfer(REPEAT(A,20), x, 20), b, a), string ) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #5 from patchapp at dberlin dot org 2007-05-29 06:45 --- Subject: Bug number PR31610 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01953.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-29 13:17 --- (In reply to comment #3) Paul, I don't think that's solving the right problem. The code is legal; the inner TRANSFER creates an array of CHARACTER with len=1 and size=20, which conforms with a CHARACTER scalar of len=20. I do not agree. The standard does not demand that the arguments conform but that 9.3.96 MERGE (TSOURCE, FSOURCE, MASK) Description: Selects between two values or between corresponding elements in two arrays, according to the condition specified by a logical mask. Class: Elemental function; Generic Arguments: TSOURCE Must be a scalar or array (of any data type). FSOURCE Must be a scalar or array of the same type and type parameters as TSOURCE. MASK Must be a logical array. Results: The result type is the same as TSOURCE. The value of MASK determines whether the result value is taken from TSOURCE (if MASK is true) or FSOURCE (if MASK is false). According to 2.4.1.1, the type parameters are KIND and LEN. I think that the g95 and sun messages are correct. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-29 13:39 --- (In reply to comment #4) I misunderstood something slightly in that last comment; MERGE is elemental, so the conforming I mentioned doesn't matter. Also, my guess that fixing the transfer(A, x, 20) problem would fix the whole thing proved to be incorrect. See comment #6. So, even once the first bit is fixed, if we change the code to be legitimate, as follows, then it still has an error: character(len=20) :: string logical :: a(20) write(*,*) transfer (merge (transfer(A, x, 20), b, a), string ) end It also fails with a character(len = 1) array of size 20. Specifically, we ICE by failing the gcc_assert (integer_zerop (loop - from[n])) at line 593 of trans-array.c, when doing gfc_conv... stuff to the arguments of the outer transfer function. I'm having a bear of a time tracking down why this is happening. The problem is that we're generating a temporary, so loop-temp_dim is 1 (as set in gfc_trans_constant_array_constructor, line 1576). However, the loop seems to be picking up dimensions from the result of the inner transfer function somehow. Walking through the ss list for the loop gives a GFC_SS_CONSTRUCTOR, a GFC_SS_SCALAR, and a GFC_SS_SECTION, and the GFC_SS_SECTION causes the info-start[0] and info-end[0] values to be set (to 1 and 20, respectively) in gfc_conv_ss_startstride, which then propagate to the from[0] and to[0] values for the loop. I can't seem to duplicate this with any other set of functions. It's only happening with characters, not integers, and if I break up the expression or substitute other things for transfer and merge, it doesn't replicate this behavior. Help? I'll have a think about this tonight. I NEVER find debugging the scalarizer easy; not in small part because I have to re-understand it every time I go near it. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #8 from burnus at gcc dot gnu dot org 2007-05-29 14:05 --- In reducing this, I discovered that gfortran currently hangs on the following much simpler code. I suspect that if we fix this, it'll fix the original code too. write(*,*) transfer(A, x, 20) NAG f95 and g95 print for that case the (default-shown) warning: Warning: Intrinsic TRANSFER has partly undefined result and Warning (148): Not enough data to produce the requested array size in TRANSFER function at (1) NAG f95, ifort and g95 print A (sunf95 prints A2#65533;Uh2#65533;U). Such a compile-time warning for transfer(...,...,size) would be also nice to have in gfortran. For the original test case (comment 0, see also comment 1): - f95 and g95 print the same warning plus the error (g95: see comment 2): Error: Unequal character lengths (1 and 20) in MERGE intrinsic - ifort accepts it and returns a zero-length string - sunf95 prints an error (see comment 1) character(len=20) :: string logical :: a(20) write(*,*) transfer (merge (transfer(A, x, 20), b, a), string ) end This gives still a warning with g95 and NAG f95; NAG outputs Abb, ifort/g95/sunf95 show . I agree with Paul, NAGf95 and g95 that merge needs to have same-character-length strings. -- 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=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #9 from dominiq at lps dot ens dot fr 2007-05-29 14:25 --- This gives still a warning with g95 and NAG f95; NAG outputs Abb, ifort/g95/sunf95 show . Since a(:) is not initialized, the output can be anything. with a = .false. a(1) = .true. I get 'Abbb' with both xlf and g95, otherwise the outputs differ. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #3 from brooks at gcc dot gnu dot org 2007-05-28 21:09 --- Paul, I don't think that's solving the right problem. The code is legal; the inner TRANSFER creates an array of CHARACTER with len=1 and size=20, which conforms with a CHARACTER scalar of len=20. In reducing this, I discovered that gfortran currently hangs on the following much simpler code. I suspect that if we fix this, it'll fix the original code too. write(*,*) transfer(A, x, 20) end -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-04-18 07:03:32 |2007-05-28 21:09:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #4 from brooks at gcc dot gnu dot org 2007-05-29 05:59 --- I misunderstood something slightly in that last comment; MERGE is elemental, so the conforming I mentioned doesn't matter. Also, my guess that fixing the transfer(A, x, 20) problem would fix the whole thing proved to be incorrect. So, even once the first bit is fixed, if we change the code to be legitimate, as follows, then it still has an error: character(len=20) :: string logical :: a(20) write(*,*) transfer (merge (transfer(A, x, 20), b, a), string ) end Specifically, we ICE by failing the gcc_assert (integer_zerop (loop - from[n])) at line 593 of trans-array.c, when doing gfc_conv... stuff to the arguments of the outer transfer function. I'm having a bear of a time tracking down why this is happening. The problem is that we're generating a temporary, so loop-temp_dim is 1 (as set in gfc_trans_constant_array_constructor, line 1576). However, the loop seems to be picking up dimensions from the result of the inner transfer function somehow. Walking through the ss list for the loop gives a GFC_SS_CONSTRUCTOR, a GFC_SS_SCALAR, and a GFC_SS_SECTION, and the GFC_SS_SECTION causes the info-start[0] and info-end[0] values to be set (to 1 and 20, respectively) in gfc_conv_ss_startstride, which then propagate to the from[0] and to[0] values for the loop. I can't seem to duplicate this with any other set of functions. It's only happening with characters, not integers, and if I break up the expression or substitute other things for transfer and merge, it doesn't replicate this behavior. Help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-19 20:47 ---
(In reply to comment #1)
This does the trick but I haven't checked against the standard, nor have I
regtested.
Paul
Index: /svn/trunk/gcc/fortran/check.c
===
*** /svn/trunk/gcc/fortran/check.c (revision 123643)
--- /svn/trunk/gcc/fortran/check.c (working copy)
*** static try
*** 218,224
same_type_check (gfc_expr *e, int n, gfc_expr *f, int m)
{
if (gfc_compare_types (e-ts, f-ts))
! return SUCCESS;
gfc_error ('%s' argument of '%s' intrinsic at %L must be the same type
and kind as '%s', gfc_current_intrinsic_arg[m],
--- 218,241
same_type_check (gfc_expr *e, int n, gfc_expr *f, int m)
{
if (gfc_compare_types (e-ts, f-ts))
! {
! if (e-ts.type != BT_CHARACTER)
! return SUCCESS;
!
! else if (e-ts.cl-length
!e-ts.cl-length-expr_type == EXPR_CONSTANT
!f-ts.cl-length
!f-ts.cl-length-expr_type == EXPR_CONSTANT
!mpz_cmp (e-ts.cl-length-value.integer,
! f-ts.cl-length-value.integer) != 0)
! {
! gfc_error ('%s' argument of '%s' intrinsic at %L must have
!the same character length as '%s',
!gfc_current_intrinsic_arg[m], gfc_current_intrinsic,
!f-where, gfc_current_intrinsic_arg[n]);
! return FAILURE;
! }
! }
gfc_error ('%s' argument of '%s' intrinsic at %L must be the same type
and kind as '%s', gfc_current_intrinsic_arg[m],
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-04-18 07:03
---
g95:
string = transfer(merge (transfer(achar (ichar('A')), x, len(string)), st
1
Error: MERGE intrinsic at (1) has different character lengths
Sun:
string = transfer(merge (transfer(achar (ichar('A')), x, len(string)),
string, a), repeat(x, len(string)) )
^
pr31610.f90, Line = 3, Column = 78: ERROR: Improper intrinsic argument type
or inconsistent types.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-04-18 07:03:32
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
