[Bug fortran/15809] New: ICE Using Pointer Functions

[Bug fortran/15809] New: ICE Using Pointer Functions

[giese025 at tc dot umn dot edu]

The file foo.f95 compiles without error nor warning with the NAG f95 compiler
but produces an internal compiler error with g95 (x86 Linux Binary (06/02/04)
from http://www.g95.org).

The error messege produced is:
foo.f95: In function `reallocate_hnv__':
foo.f95:1: internal compiler error: in find_function_data, at function.c:311

This was performed on a Redhat 9 machine.

The program simply contains a function and a subroutine.  The function produces
a pointer of a specified vector length and fills in the array from an input
pointer.  The input pointer is then deallocated.

The function itself will compile fine, but produces the ICE when used in another
subroutine.

foo.f95 will be submitted as an attachment in the next comment.

-- 
           Summary: ICE Using Pointer Functions
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: giese025 at tc dot umn dot edu
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/15809] ICE Using Pointer Functions

[giese025 at tc dot umn dot edu]

------- Additional Comments From giese025 at tc dot umn dot edu  2004-06-03 20:13 -------
Created an attachment (id=6460)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6460&action=view)
Test program to reproduce ICE

Attached file that reproduces the internal compiler error.

-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-03 20:21 -------
There is a different bug in gfortran with this code:
f951: /home/gates/pinskia/src/gnu/gcc/src/gcc/fortran/trans-array.c:184: gfc_conv_descriptor_data: 
Assertion `(__extension__ ({ const tree __t = (type); if (tree_code_type[(int) (((enum tree_code) (__t)-
>common.code))] != ('t')) tree_class_check_failed (__t, ('t'), "/home/gates/pinskia/src/gnu/gcc/src/gcc/
fortran/trans-array.c", 184, __FUNCTION__); __t; })->type.lang_flag_1)' failed.

Note gfortran and g95 are two different projects, gfortran forked off of g95 to so that the source would 
be more available and intergrated with the GCC project, gfortran is now included in snapshots of 3.5.0.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2004-06-03 20:21:06
               date|                            |


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

[Bug fortran/15809] ICE Using Pointer Functions

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-07-11 17:10 -------
Reduced testcase:
  SUBROUTINE A(p,LEN)
    CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p
    IF ( .NOT. ASSOCIATED(p) ) THEN
    END IF
  END SUBROUTINE A


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[tobi at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |17193


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

[Bug fortran/15809] ICE Using Pointer Functions

[c dot lemmen at fz-juelich dot de]

------- Additional Comments From c dot lemmen at fz-juelich dot de  2004-09-22 07:48 -------
Confirmed with GNU F95 version 4.0.0 20040921 on Sep-22, 2004
Problem only occurs when the pointer is an <strong>argument</strong> to the
function and not with logical,real,integer types

Note that this error occurs on line 183 now:
internal compiler error: in gfc_conv_descriptor_data, at fortran/trans-array.c:183


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-14 17:53 -------
*** Bug 18991 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tow21 at cam dot ac dot uk


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

[Bug fortran/15809] ICE Using Pointer Functions

[szalai at mit dot edu]

------- Additional Comments From szalai at mit dot edu  2005-04-03 02:25 -------
This also occurs with the MUMPS parallel solver library.  
The testcase testcase in this report now occurs as follows:  
  
test5.f: In function ‘a’:  
test5.f:1: internal compiler error: in gfc_conv_descriptor_data, at  
fortran/trans-array.c:144  
Please submit a full bug report,  
with preprocessed source if appropriate.  
See <URL:http://gcc.gnu.org/bugs.html> for instructions.  
 
The compiler version 
gcc version 4.0.0 20050326 (prerelease) 
(this is a snapshot) 

-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[pault at gcc dot gnu dot org]

-- 
Bug 15809 depends on bug 17193, which changed state.

Bug 17193 Summary: [meta-bug] Pointer arguments not working correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17193

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

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

[Bug fortran/15809] ICE Using Pointer Functions

[erik dot edelmann at iki dot fi]

------- Additional Comments From erik dot edelmann at iki dot fi  2005-08-30 20:28 -------
Hmm ... With current version of gfortran (4.1.0 20050830), the reduced testcase
by Tobias gives the error message

bug.f90: In function 'a':
bug.f90:3: internal compiler error: in gfc_trans_deferred_array, at
fortran/trans-array.c:4005

while the original testcase by Tim gives

bug2.f90: In function 'allocateifneeded_hnv':
bug2.f90:38: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:1107

I think we are dealing with (at least) two different non-related bugs here.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |erik dot edelmann at iki dot
                   |                            |fi


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

[Bug fortran/15809] ICE Using Pointer Functions

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2005-08-31 19:35 -------
Probably Paul Thomas' character fixes play a role in making those two different
bugs.

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


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

[Bug fortran/15809] ICE Using Pointer Functions

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2005-09-02 11:34 -------
According to Erik Richard's patch for PR15326 fixes one of those two bugs (I
assume the latter?), adding the dependency so that we will keep track of this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |15326


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

[Bug fortran/15809] ICE Using Pointer Functions

[erik dot edelmann at iki dot fi]

------- Additional Comments From erik dot edelmann at iki dot fi  2005-09-02 11:56 -------
(In reply to comment #9)
> According to Erik Richard's patch for PR15326 fixes one of those two bugs (I
> assume the latter?), adding the dependency so that we will keep track of this.

Yes, it's the latter bug that Richard's patch fixes.

I could add that I posted a patch to fix the other bug here:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01861.html
I'm not yet sure if this is the best way to deal with the problem, though.

-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

------- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de  2005-09-02 15:38 -------
Subject: Re:  ICE Using Pointer Functions

erik dot edelmann at iki dot fi wrote:
> Yes, it's the latter bug that Richard's patch fixes.
> 
> I could add that I posted a patch to fix the other bug here:
> http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01861.html
> I'm not yet sure if this is the best way to deal with the problem, though.

I vaguely remember seeing a case where allowing a PARM_DECL fixed a bug, but
wasn't still not quite right.  I'll try to find out what this was (hopefully
I'll have somethign written somewhere on it)

- Tobi


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[erik dot edelmann at iki dot fi]

------- Additional Comments From erik dot edelmann at iki dot fi  2005-09-06 21:10 -------
With my patch, the reduced testcase by Tobi compiles, but this slightly longer
testcase doesn't:

$ cat bug7.f90 
SUBROUTINE A(p,LEN)
    CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p
    IF ( .NOT. ASSOCIATED(p) ) THEN
        allocate(p(1))
    END IF
END SUBROUTINE A
$ gfortran bug7.f90 
bug7.f90: In function 'a':
bug7.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

I'm not yet sure if it is because my patch doesn't solve the bug after all, or
if this is yet another unrelated bug.


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[rsandifo at gcc dot gnu dot org]

-- 
Bug 15809 depends on bug 15326, which changed state.

Bug 15326 Summary: ICE with assumed length character strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15326

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

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

[Bug fortran/15809] ICE Using Pointer Functions

[tkoenig at gcc dot gnu dot org]

-- 
Bug 15809 depends on bug 15326, which changed state.

Bug 15326 Summary: [4.0 only] ICE with assumed length character strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15326

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

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

[Bug fortran/15809] ICE Using Pointer Functions

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.1.0


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

[Bug fortran/15809] ICE Using Pointer Functions

[pault at gcc dot gnu dot org]

------- Comment #22 from pault at gcc dot gnu dot org  2005-12-07 06:20 -------
Subject: Bug 15809

Author: pault
Date: Wed Dec  7 06:20:21 2005
New Revision: 108150

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108150
Log:
2005-12-07  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/15809
        * trans-decl.c (gfc_get_symbol_decl):  In the case of automatic
        character length, dummy pointer arrays, build an expression for
        unit size of the array elements, to be picked up and used in the
        descriptor dtype.
        * trans-io.c (gfc_trans_transfer):  Modify the detection of
        components of derived type arrays to use the gfc_expr references
        instead of the array descriptor dtype.  This allows the latter
        to contain expressions.

2005-12-07  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/15809
        *  gfortran.dg/auto_char_dummy_array.f90: New test.

Added:
   
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/auto_char_dummy_array_1.f90
Modified:
    branches/gcc-4_1-branch/gcc/fortran/ChangeLog
    branches/gcc-4_1-branch/gcc/fortran/trans-array.c
    branches/gcc-4_1-branch/gcc/fortran/trans-decl.c
    branches/gcc-4_1-branch/gcc/fortran/trans-io.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[jakub at gcc dot gnu dot org]

------- Comment #21 from jakub at gcc dot gnu dot org  2005-12-05 11:14 -------
Subject: Bug 15809

Author: jakub
Date: Mon Dec  5 11:14:10 2005
New Revision: 108052

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108052
Log:
        PR fortran/15809
        * trans-decl.c (gfc_get_symbol_decl): Revert 2005-11-30 and
        2005-12-01 changes.
        (gfc_trans_vla_type_sizes): Also "gimplify"
        GFC_TYPE_ARRAY_DATAPTR_TYPE for GFC_DESCRIPTOR_TYPE_P types.
        * trans-array.c (gfc_trans_deferred_array): Call
        gfc_trans_vla_type_sizes.

Modified:
    branches/gomp-20050608-branch/gcc/fortran/ChangeLog.gomp
    branches/gomp-20050608-branch/gcc/fortran/trans-array.c
    branches/gomp-20050608-branch/gcc/fortran/trans-decl.c


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[pault at gcc dot gnu dot org]

------- Comment #20 from pault at gcc dot gnu dot org  2005-11-30 19:26 -------
Fixed on trunk, just waiting 24 hours before fixing in 4.0 and 4.1


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug fortran/15809] ICE Using Pointer Functions

[pault at gcc dot gnu dot org]

------- Comment #19 from pault at gcc dot gnu dot org  2005-11-30 17:26 -------
Subject: Bug 15809

Author: pault
Date: Wed Nov 30 17:26:40 2005
New Revision: 107727

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107727
Log:
2005-11-30  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/15809
        * trans-decl.c (gfc_get_symbol_decl):  In the case of automatic
        character length, dummy pointer arrays, build an expression for
        unit size of the array elements, to be picked up and used in the
        descriptor dtype.
        * trans-io.c (gfc_trans_transfer):  Modify the detection of
        components of derived type arrays to use the gfc_expr references
        instead of the array descriptor dtype.  This allows the latter
        to contain expressions.

2005-11-30  Erik Edelmann  <erik.edelmann@iki.fi>

        PR fortran/15809
        * trans-array.c (gfc_trans_deferred_array):  Allow PARM_DECLs past
        in addition to VAR_DECLs.

2005-11-30  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/15809
        *  gfortran.dg/auto_char_dummy_array.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/auto_char_dummy_array_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-io.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[paul dot richard dot thomas at cea dot fr]

------- Comment #18 from paul dot richard dot thomas at cea dot fr  2005-11-23 14:26 -------
(In reply to comment #15)
> I cannot tell why, but it seems to me that Paul Thomas' test case is no valid

Hej Sven!

You quite correctly picked up that it does not have an explicit interface and
so will give nonsense.  Making it contained or writing an interface converts my
rubbish into legal code.

I have made progress in converting pointer arrays into references to pointer
arrays:

The patch below works for pointer assignments with integers and characters and
returns pointer dummy arguments correctly.

There is still a problem (seg fault) with assignments of characters. This comes
about because dtype does not contain the size, as is apparent from the code at
the end of the message. (see the dtypes in the subroutine).

There are also some issues with alignment during pointer assignments.

This damn thing is going to work, legal fortran or not!!!!

Both the examples below work.

                                                      Paul Thomas 23rd Nov 2005


Danger: Cygwin source => whitespace issues.

*** trunk/gcc/fortran/trans-array.c     Wed Nov 23 14:44:18 2005
--- trunk/gcc/fortran/trans-array.c.orig        Wed Nov 23 14:45:15 2005
*************** gfc_trans_deferred_array (gfc_symbol * s
*** 4173,4179 ****

    gfc_init_block (&fnblock);

!   gcc_assert (TREE_CODE (sym->backend_decl) == VAR_DECL);
    if (sym->ts.type == BT_CHARACTER
        && !INTEGER_CST_P (sym->ts.cl->backend_decl))
      gfc_trans_init_string_length (sym->ts.cl, &fnblock);
--- 4173,4181 ----

    gfc_init_block (&fnblock);

!   gcc_assert (TREE_CODE (sym->backend_decl) == VAR_DECL
!                 || TREE_CODE (sym->backend_decl) == PARM_DECL);
!
    if (sym->ts.type == BT_CHARACTER
        && !INTEGER_CST_P (sym->ts.cl->backend_decl))
      gfc_trans_init_string_length (sym->ts.cl, &fnblock);

*** trunk/gcc/fortran/trans-expr.c      Wed Nov 23 14:55:20 2005
--- trunk/gcc/fortran/trans-expr.c.orig Wed Nov 23 14:56:37 2005
*************** gfc_conv_variable (gfc_se * se, gfc_expr
*** 396,401 ****
--- 396,404 ----
                  || !sym->attr.dimension))
            se->expr = gfc_build_indirect_ref (se->expr);
        }
+
+       if (sym->attr.pointer && sym->attr.dummy && sym->attr.dimension)
+         se->expr = gfc_build_indirect_ref (se->expr);

        ref = expr->ref;
      }
*************** gfc_conv_function_call (gfc_se * se, gfc
*** 1608,1614 ****
                  && !formal->sym->attr.pointer
                  && formal->sym->as->type != AS_ASSUMED_SHAPE;
              f = f || !sym->attr.always_explicit;
!             gfc_conv_array_parameter (&parmse, arg->expr, argss, f);
            }
        }

--- 1611,1619 ----
                  && !formal->sym->attr.pointer
                  && formal->sym->as->type != AS_ASSUMED_SHAPE;
              f = f || !sym->attr.always_explicit;
!             gfc_conv_array_parameter (&parmse, arg->expr, argss, f);
!             if (formal != NULL && formal->sym->attr.pointer &&
formal->sym->attr.dimension)
!               parmse.expr = gfc_build_addr_expr (NULL, parmse.expr);
            }
        }


*** trunk/gcc/fortran/trans-types.c     Wed Nov 23 13:48:37 2005
--- trunk/gcc/fortran/trans-types.c.orig        Wed Nov 23 13:49:06 2005
*************** gfc_sym_type (gfc_symbol * sym)
*** 1333,1338 ****
--- 1333,1342 ----
          }
        else
        type = gfc_build_array_type (type, sym->as);
+
+       if (sym->attr.pointer && sym->attr.dummy)
+       type = build_reference_type (type);
+
      }
    else
      {


!=============================================================================
module global
    CHARACTER(14), DIMENSION(2), target :: t
end module global

program oh_no_not_pr15908_again
    CHARACTER(12), DIMENSION(:), POINTER :: ptr
    allocate (ptr(2))
    ptr = "xyz"
    call a (ptr, 12)
    IF ( .NOT. ASSOCIATED(ptr) ) THEN
        print *, "not associated in MAIN"
    else
        print *, "associated in MAIN    ", size(ptr,1), len (ptr), ptr
    END IF
contains

SUBROUTINE A(p, l)
    use global
    CHARACTER(l), DIMENSION(:), POINTER :: p

    t = "abc"
    IF ( .NOT. ASSOCIATED(p) ) THEN
        p => t
        print *, "not associated in A   ", size(p,1), len (p), p
    else
        print *, "associated in A       ", size(p,1), len (p), p
        t = "lmn"
        p => t
    END IF
END SUBROUTINE A

end program oh_no_not_pr15908_again

!=========================integer version=========================
module global
    integer, DIMENSION(2), target :: t
end module global

    integer, DIMENSION(:), POINTER :: ptr
    allocate (ptr(2))
    ptr = 123
    IF ( .NOT. ASSOCIATED(ptr) ) THEN
        print *, "not associated in MAIN"
    else
        print *, "associated in MAIN    ", size(ptr,1), ptr
    END IF
    call a (ptr, 12)
    IF ( .NOT. ASSOCIATED(ptr) ) THEN
        print *, "not associated in MAIN"
    else
        print *, "associated in MAIN    ", size(ptr,1), ptr
    END IF
contains

SUBROUTINE A(p, l)
    use global
    integer, DIMENSION(:), POINTER :: p
    t = 456
    IF ( .NOT. ASSOCIATED(p) ) THEN
        p => t
        print *, "not associated in A   ", size(p,1), p
    else
        print *, "associated in A       ", size(p,1), p
        t = 789
        p => t
        print *, "associated in A       ", size(p,1), p
    END IF
END SUBROUTINE A
end

=========================code for character version====================

a (p, l, _p)
{
  extern char t[2][1:14];
  int4 .p;

  .p = *l;
  {
    int4 S.0;

    S.0 = 1;
    while (1)
      {
        if (S.0 > 2) goto L.1; else (void) 0;
        _gfortran_copy_string (14, &t[NON_LVALUE_EXPR <S.0> + -1], 3, "abc");
        S.0 = S.0 + 1;
      }
    L.1:;
  }
  if ((char[0:][1:] *) (*p)->data != 0B == 0)
    {
      (*p)->dtype = 49;
      (*p)->dim[0].lbound = 1;
      (*p)->dim[0].ubound = 2;
      (*p)->dim[0].stride = 1;
      (*p)->data = (void *) (char[0:][1:14] *) &t[0];
      (*p)->offset = -1;
      _gfortran_filename = "pr15809.f90";
      _gfortran_line = 24;
      _gfortran_ioparm.unit = 6;
      _gfortran_ioparm.list_format = 1;
      _gfortran_st_write ();
      _gfortran_transfer_character ("not associated in A   ", 22);
      {
        int4 D.577;

        D.577 = _gfortran_size1 ((struct array1_unknown *) *p, 1);
        _gfortran_transfer_integer (&D.577, 4);
      }
      {
        int4 D.578;

        D.578 = .p;
        _gfortran_transfer_integer (&D.578, 4);
      }
      _gfortran_transfer_array ((struct array1_unknown *) *p, 1, .p);
      _gfortran_st_write_done ();
    }
  else
    {
      _gfortran_filename = "pr15809.f90";
      _gfortran_line = 26;
      _gfortran_ioparm.unit = 6;
      _gfortran_ioparm.list_format = 1;
      _gfortran_st_write ();
      _gfortran_transfer_character ("associated in A       ", 22);
      {
        int4 D.579;

        D.579 = _gfortran_size1 ((struct array1_unknown *) *p, 1);
        _gfortran_transfer_integer (&D.579, 4);
      }
      {
        int4 D.580;

        D.580 = .p;
        _gfortran_transfer_integer (&D.580, 4);
      }
      _gfortran_transfer_array ((struct array1_unknown *) *p, 1, .p);
      _gfortran_st_write_done ();
      {
        int4 S.1;

        S.1 = 1;
        while (1)
          {
            if (S.1 > 2) goto L.2; else (void) 0;
            _gfortran_copy_string (14, &t[NON_LVALUE_EXPR <S.1> + -1], 3,
"lmn";
            S.1 = S.1 + 1;
          }
        L.2:;
      }
      (*p)->dtype = 49;
      (*p)->dim[0].lbound = 1;
      (*p)->dim[0].ubound = 2;
      (*p)->dim[0].stride = 1;
      (*p)->data = (void *) (char[0:][1:14] *) &t[0];
      (*p)->offset = -1;
    }
}


MAIN__ ()
{
  struct array1_unknown ptr;
  static void a (struct array1_unknown & &, int4 &, int4);

  ptr.data = 0B;
  {
    void * * D.584;

    ptr.dtype = 1585;
    ptr.dim[0].lbound = 1;
    ptr.dim[0].ubound = 2;
    ptr.dim[0].stride = 1;
    D.584 = &ptr.data;
    _gfortran_allocate (D.584, 48, 0);
    ptr.offset = -1;
  }
  {
    int4 D.587;
    int4 D.586;
    char[0:][1:24] * D.585;

    D.585 = (char[0:][1:24] *) ptr.data;
    D.586 = ptr.offset;
    D.587 = ptr.dim[0].lbound;
    {
      int4 D.589;
      int4 S.2;

      D.589 = ptr.dim[0].stride;
      S.2 = D.587;
      while (1)
        {
          if (S.2 > ptr.dim[0].ubound) goto L.3; else (void) 0;
          _gfortran_copy_string (24, &(*D.585)[NON_LVALUE_EXPR <S.2> * D.589 +
.586], 3, "xyz");
          S.2 = S.2 + 1;
        }
      L.3:;
    }
  }
  {
    int4 C.591 = 12;

    a (&&ptr, &C.591, 24);
  }
  if ((char[0:][1:24] *) ptr.data != 0B == 0)
    {
      _gfortran_filename = "pr15809.f90";
      _gfortran_line = 11;
      _gfortran_ioparm.unit = 6;
      _gfortran_ioparm.list_format = 1;
      _gfortran_st_write ();
      _gfortran_transfer_character ("not associated in MAIN", 22);
      _gfortran_st_write_done ();
    }
  else
    {
      _gfortran_filename = "pr15809.f90";
      _gfortran_line = 13;
      _gfortran_ioparm.unit = 6;
      _gfortran_ioparm.list_format = 1;
      _gfortran_st_write ();
      _gfortran_transfer_character ("associated in MAIN    ", 22);
      {
        int4 D.592;

        D.592 = _gfortran_size1 (&ptr, 1);
        _gfortran_transfer_integer (&D.592, 4);
      }
      {
        int4 C.593 = 24;

        _gfortran_transfer_integer (&C.593, 4);
      }
      _gfortran_transfer_array (&ptr, 1, 24);
      _gfortran_st_write_done ();
    }
}


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[pault at gcc dot gnu dot org]

------- Comment #17 from pault at gcc dot gnu dot org  2005-11-22 20:16 -------
I have started to see a light at the end of the tunnel.  Going back to easier
but related things, I have found that this is broken, as is its character
cousin:

    integer, DIMENSION(:), POINTER :: ptr
    allocate (ptr(2))
    ptr = 123
    call a (ptr, 12)
    IF ( .NOT. ASSOCIATED(ptr) ) THEN
        print *, "not associated in MAIN"
    else
        print *, "associated in MAIN    ", size(ptr,1), ptr
    END IF
contains

SUBROUTINE A(p, l)
    integer, DIMENSION(:), POINTER :: p
    integer, DIMENSION(2), target :: t
    t = 456
    IF ( .NOT. ASSOCIATED(p) ) THEN
        p => t
        print *, "not associated in A   ", size(p,1), p
    else
        print *, "associated in A       ", size(p,1), p
        t = 789
        p => t
    END IF
END SUBROUTINE A

end

The subroutine works but the wrong result is returned.  The reason for this is
now abundantly clear, although why it was not so before is not....*sigh*

A pointer array is passed as an array descriptor; this means that the value is
not returned if the association is changed!

I have most of the way cured this, up to backend complaints about violating the
sanctity of pointers (I need to get the PARM_DECL to be of the right type but
have all the indirect referencing sorted out.).

Paul


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

------- Comment #16 from Tobias dot Schlueter at physik dot uni-muenchen dot de  2005-11-21 18:08 -------
Subject: Re:  ICE Using Pointer Functions

pgf90 compiles Paul Thomas' example, giving an empty string as output from the
subroutine.


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[sven dot buijssen at math dot uni-dortmund dot de]

------- Comment #15 from sven dot buijssen at math dot uni-dortmund dot de  2005-11-21 18:06 -------
I cannot tell why, but it seems to me that Paul Thomas' test case is no valid
code:

* Compaq Fortran Compiler X5.4A-1684-46B5P gives:
f90: Warning: line 14: An explicit-shaped array is being passed to a routine
that expects a pointer or assumed-shape array
  call a (ptr)
----------^

Ok, that's because of the spare dummy argument l in the subroutine definition.
Omitting it, Compaq compiles, decides that p is associated, but prints an empty
string.

* Same behaviour with g95 (Nov 12 2005): empty string

* Next compiler: Sun Fortran 95 8.1 Patch 117834-03 2005/06/15
The Sun Compiler totally refuses to compile Paul Thomas' test case (but
omitting the spare dummy argument l):

  call a (ptr)
  ^
Line = 14, Column = 3: ERROR: Procedure "A" is defined at line 1.  It must have
an explicit interface specified.

f90comp: 16 SOURCE LINES
f90comp: 1 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI

* Rewriting the code to something equivalent

program demo

  character(8), dimension (:), pointer :: ptr
  character(8), dimension (2), target :: tar
  tar = "def"
  ptr => tar
  call a (ptr)
  if (associated (ptr)) print *, "in MAIN, ptr = ", ptr

contains
  subroutine a(p)
    character(8), dimension(:), pointer :: p
    if (associated (p)) then
      print *, p
    else
      print *, "not associated"
    end if
  end subroutine a

end program demo

solves all problems. g95, gfortran (20051113), ifort 9.0, Sun + Compaq Compiler
smoothly compile and print to screen the desired:

 def     def
 in MAIN, ptr = def     def


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[pault at gcc dot gnu dot org]

------- Comment #14 from pault at gcc dot gnu dot org  2005-11-21 15:53 -------
I have become more than a little bit concerned that this PR is a wild goose
chase.

Applying a similar patch to Erik's, I can persuade some bits of code to do
something.  Furthermore, they are even the same things that ifort9.0 does;
right down to segfaulting in the same places... mostly!  However, getting
anything useful out of such subroutines, even with ifort, is defeating me.

>From 12.4.1.1....

"If the dummy argument is a pointer, the actual argument shall be a pointer and
the types, type parameters and ranks shall agree."

Does this not make an automatic, character-length, pointer dummy incorrect
code?

"At the invocation of the procedure, the dummy argument pointer receives the
pointer association status of the actual argument.  If the actual argument is
currently associated, the the dummy argument becomes associated with the same
target... "  

Thus encouraged, I wrote this:

  SUBROUTINE A(p,l)
    CHARACTER(8), DIMENSION(:), pointer :: p
    if (associated (p)) then
      print *, p
    else
      print *, "not associated"
    end if
  END SUBROUTINE A

  character(8), dimension (:), pointer :: ptr
  character(8), dimension (2), target :: tar
  tar = "def"
  ptr => tar
  call a (ptr)
  if (associated (ptr)) print *, "in MAIN, ptr = ", ptr
  end

ifort decides that p is not associated, whilst gfortran finds p to be
associated but fails to recognise that p is a character and produces a "bad
real" message at the print statement.

It seems to me that, in gfortran, the dummy needs to be declared in the
procedure and its data pointer set to that of the actual argument.  Whether an
automatic character length should work or not seems to be moot to me.


-- 


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

[Bug fortran/15809] ICE Using Pointer Functions

[sven dot buijssen at math dot uni-dortmund dot de]

------- Comment #13 from sven dot buijssen at math dot uni-dortmund dot de  2005-10-23 13:34 -------
In the meantime with gfortran 4.0.2 and the latest CVS version of gfortran (GNU
F95 version 4.1.0 20051023 (experimental)) again both Tobi's and Erik's
testcases give ICEs, both different ones:

# Tobi's testcase
$ cat bug7.f90 
SUBROUTINE A(p,LEN)
    CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p
    IF ( .NOT. ASSOCIATED(p) ) THEN
    END IF
END SUBROUTINE A
$ gfortran bug7.f90 
bug7.f90: In function 'a':
bug7.f90:3: internal compiler error: in gfc_trans_deferred_array, at
fortran/trans-array.c:4163

# Erik's testcase
$ cat bug7a.f90 
SUBROUTINE A(p,LEN)
    CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p
    IF ( .NOT. ASSOCIATED(p) ) THEN
        allocate(p(1))
    END IF
END SUBROUTINE A
$ gfortran bug7a.f90 
bug7a.f90: In function 'a':
bug7a.f90:1: internal compiler error: Segmentation fault


Both testcases, however, compile smoothly when replacing CHARACTER(LEN=LEN) by
something fixed, e.g. CHARACTER(LEN=5). So, assigning a fixed length is a
possible workaround for those that are affected by this bug, like I am.

Investigating this bug further one finds:
1) Tobi's testcase with assumed-length character, CHARACTER(LEN=*), compiles
smoothly as well, while Erik's testcase with CHARACTER(LEN=*) gives again
bug7a.f90: In function 'a':
bug7a.f90:1: internal compiler error: Segmentation fault

2) The problem seems to be that accessing a member of the array p, e.g. via 
    print *, p(1)
   or via 'allocate' as in Erik's test case, causes an ICE if and if only an
assumed-length character is used. CHARACTER(LEN=<some number>) works.

3) Fixing this bug will probably also fix the ICE for the following invalid (!)
code 
$ cat bug7c.f90 
  function foo()
    character(len=*),dimension(:),pointer :: foo
    allocate(foo(1))
  end function
$ gfortran -c bug7c.f90
bug3.f90: In function 'foo':
bug3.f90:1: internal compiler error: Segmentation fault

while it simply gives errors with ifort 9.0 20050809
> fortcom: Error: bug3.f90, line 1: A CHARACTER function name must not be declared with an asterisk type-param-value (i.e., (LEN=*)) if the function is array-valued. 
and g95 (G95 (GCC 4.0.1 (g95!) Oct 16 2005))
> Error: POINTER valued function 'foo' at (1) cannot return an assumed-length character (*)

As previously, this problem only occurs if assumed-length character is used
instead of a fixed length.

I hope this information will help tracing the error.


For sake of completeness:
$ gfortran -v                    
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcccvs/configure --enable-shared
--prefix=/usr/local/gcc-4.0.x-cvs --enable-languages=c,c++,fortran
--enable-threads --enable-__cxa_atexit
Thread model: posix
gcc version 4.1.0 20051023 (experimental)

$ gfortran-4.0.2 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure --enable-shared
--prefix=/usr/local/gcc-4.0.2 --enable-languages=c,c++,f95 --enable-threads
--enable-__cxa_atexit
Thread model: posix
gcc version 4.0.2

Environment:
System: Linux stingray 2.6.8-24.18-default #1 Fri Aug 19 11:56:28 UTC 2005 i686
unknown unknown GNU/Linux
Architecture: i686
glibc 2.3.4
SuSE 9.2
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu


-- 

sven dot buijssen at math dot uni-dortmund dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sven dot buijssen at math
                   |                            |dot uni-dortmund dot de
Bug 15809 depends on bug 15326, which changed state.

Bug 15326 Summary: [4.0 only] ICE with assumed length character strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15326

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

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