[Bug fortran/31610] New: ICE with transfer, merge in gfc_conv_expr_descriptor

[Bug fortran/31610] New: ICE with transfer, merge in gfc_conv_expr_descriptor

[pinskia at gcc dot gnu dot org]

Testcase (4.3.0 20070415):
    Character(len=20) string
    Logical, Dimension(20) :: a
    string = transfer(merge (transfer(achar (ichar('A')), "x", len(string)),
string, a), repeat("x", len(string)) )
end


-- 
           Summary: ICE with transfer, merge in gfc_conv_expr_descriptor
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia 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

[fxcoudert at gcc dot gnu dot org]

------- 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|0000-00-00 00:00:00         |2007-04-18 07:03:32
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610

[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor

[pault at gcc dot gnu dot org]

------- 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

[brooks at gcc dot gnu dot org]

------- 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

[brooks at gcc dot gnu dot org]

------- 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

[patchapp at dberlin dot org]

------- 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

[pault at gcc dot gnu dot org]

------- 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

[pault at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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�Uh2�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 "Abbbbbb",
ifort/g95/sunf95 show "bbbbbbbbbbbbbbbbbbbb".

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

[dominiq at lps dot ens dot fr]

------- 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 "Abbbbbb",
> ifort/g95/sunf95 show "bbbbbbbbbbbbbbbbbbbb".

Since a(:) is not initialized, the output can be anything.
with 

a = .false.
a(1) = .true.

I get 'Abbbbbbbbbbbbbbbbbbb' 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

[burnus at gcc dot gnu dot org]

------- 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

[fxcoudert at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]



------- 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

[fxcoudert at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]



------- 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

[jvdelisle at gcc dot gnu dot org]

------- 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] [4.3 Regression] ICE with transfer, merge in gfc_conv_expr_descriptor

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2008-01-25 20:21 -------
Regressions should have a target-milestone.  Fortran is not release-critical.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610

[Bug fortran/31610] [4.3 Regression] ICE with transfer, merge in gfc_conv_expr_descriptor

[jvdelisle at gcc dot gnu dot org]

------- Comment #15 from jvdelisle at gcc dot gnu dot org  2008-01-26 02:38 -------
I have the example in comment #10 working by bypassing the assert:

Index: trans-array.c
===================================================================
--- trans-array.c       (revision 131850)
+++ trans-array.c       (working copy)
@@ -589,7 +589,7 @@ gfc_trans_create_temp_array (stmtblock_t
     {
       n = loop->order[dim];
       if (n < loop->temp_dim)
-       gcc_assert (integer_zerop (loop->from[n]));
+       gcc_assert (true);
       else
        {
          /* Callee allocated arrays may not have a known bound yet.  */

The test case in pr34946 also compiles.  Without some completely executable
code I can't say this is the fix, but maybe we are being overly assertive here.
?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610

[Bug fortran/31610] [4.3 Regression] ICE with transfer, merge in gfc_conv_expr_descriptor

[jvdelisle at gcc dot gnu dot org]

------- Comment #17 from jvdelisle at gcc dot gnu dot org  2008-01-26 04:25 -------
Cleaned up patch:

Index: trans-array.c
===================================================================
--- trans-array.c       (revision 131850)
+++ trans-array.c       (working copy)
@@ -588,9 +588,7 @@ gfc_trans_create_temp_array (stmtblock_t
   for (dim = 0; dim < info->dimen; dim++)
     {
       n = loop->order[dim];
-      if (n < loop->temp_dim)
-       gcc_assert (integer_zerop (loop->from[n]));
-      else
+      if (n >= loop->temp_dim)
        {
          /* Callee allocated arrays may not have a known bound yet.  */
           if (loop->to[n])

Regression tests OK on x86-64.  If this solves Joosts problem on 34946, its a
big two for one deal.  The reduced test cases compile and Joost's original test
from the PR case compiles.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610

[Bug fortran/31610] [4.3 Regression] ICE with transfer, merge in gfc_conv_expr_descriptor

[pault at gcc dot gnu dot org]

------- Comment #18 from pault at gcc dot gnu dot org  2008-01-26 11:49 -------
(In reply to comment #17)
> Cleaned up patch:
Jerry,

I found the equivalent:

      if (n < loop->temp_dim && !integer_zerop (loop->from[n]))
        loop->from[n] = gfc_index_zero_node;

This also bootstraps and regtests OK.  Before selecting one or the other (yours
is at least minimalist:) ), I thought to try to understand what is happening.

A bizarre fact concerns FX's or your testcase:

  integer :: i(1) = 0
  write(*,*) foo([1]+i)
end

fails but foo(i+[1]) AND foo([1] + [1]) work!

It points to something being wrong with the scalarization of operators but I am
blowed if I can see what it is.

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610

[Bug fortran/31610] [4.3 Regression] ICE with transfer, merge in gfc_conv_expr_descriptor

[dominiq at lps dot ens dot fr]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]



------- Comment #19 from dominiq at lps dot ens dot fr  2008-01-26 14:41 -------
I confirm that the ICEs are gone, however the original test case and the one in
comment #3 ouput garbage: 'A^@^@^@@sÐ@^E^@^@^@^T^@^@^@^U^G^@' for the latter on
i686-apple-darwin9.

Note that g95 gives

In file pr31610.f90:3

    string = transfer(merge (transfer(achar (ichar('A')), "x", len(string)), st
                                                               1
Warning (148): Not enough data to produce the requested array size in TRANSFER
function at (1)
In file pr31610.f90:3

    string = transfer(merge (transfer(achar (ichar('A')), "x", len(string)), st
                             1
Error: MERGE intrinsic at (1) has different character lengths

for the original test and

In file pr31610_1.f90:1

  write(*,*) "'", transfer("A", "x", 20), "'"
                                     1
Warning (148): Not enough data to produce the requested array size in TRANSFER
function at (1)

for the reduced one, the output being
'A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@'.

I hope this may help to answer the question:

> It points to something being wrong with the scalarization of operators but I am
> blowed if I can see what it is.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610

[Bug fortran/31610] [4.3 Regression] ICE with transfer, merge in gfc_conv_expr_descriptor

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2008-01-26 16:37 -------
Reply to comment #18:

 The shape of 1 is a zero size array.

 The shape of [1] is [1]

Maybe in the simplifying of the expression for ([1] + 1) the shape of 1 is
being assigned to [1] or the final simplified expression has wrong shape


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610

[Bug fortran/31610] [4.3 Regression] ICE with transfer, merge in gfc_conv_expr_descriptor

[jvdelisle at gcc dot gnu dot org]

------- Comment #21 from jvdelisle at gcc dot gnu dot org  2008-01-26 19:01 -------
Subject: Bug 31610

Author: jvdelisle
Date: Sat Jan 26 19:01:07 2008
New Revision: 131873

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131873
Log:
2008-01-26  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/31610
        * trans-array.c (gfc_trans_create_temp_array): Remove call to
        gcc_assert (integer_zerop (loop->from[n])).

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610

[Bug fortran/31610] [4.3 Regression] ICE with transfer, merge in gfc_conv_expr_descriptor

[jvdelisle at gcc dot gnu dot org]

------- Comment #22 from jvdelisle at gcc dot gnu dot org  2008-01-26 19:06 -------
Subject: Bug 31610

Author: jvdelisle
Date: Sat Jan 26 19:05:15 2008
New Revision: 131874

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131874
Log:
2008-01-26  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/31610
        * gfortran.dg/array_3.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/array_3.f90
Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610

[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor

[jvdelisle at gcc dot gnu dot org]

------- 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

[jsm28 at gcc dot gnu dot org]

------- 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

[rguenth at gcc dot gnu dot org]

------- Comment #25 from rguenth at gcc dot gnu dot org  2008-06-06 14:56 -------
4.3.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.1                       |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

[jsm28 at gcc dot gnu dot org]

------- 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

[pault at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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

[mikael at gcc dot gnu dot org]

------- 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