[Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity

[Bug fortran/46974] New: ICE with TRANSFER using a C_PTR entity

[kargl at gcc dot gnu.org]

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

           Summary: ICE with TRANSFER using a C_PTR entity
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: kargl@gcc.gnu.org


program bug1
   use ISO_C_BINDING
   implicit none
   type(c_ptr) :: m
   type mytype
     integer a, b, c
   end type mytype
   type(mytype) x
   print *, transfer(32512, x)  ! Works.
   print *, transfer(32512, m)  ! Cause ICE.
end program bug1 


laptop:kargl[206] gfc4x -c po.f90
f951: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

laptop:kargl[207] gdb
/usr/home/kargl/work/libexec/gcc/i386-unknown-freebsd9.0/4.6.0/f951
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd8.0"...
(gdb) run po.f90
Starting program:
/usr/home/kargl/work/libexec/gcc/i386-unknown-freebsd9.0/4.6.0/f951 po.f90

Program received signal SIGSEGV, Segmentation fault.
0x0814d56d in gfc_interpret_derived (buffer=0xbfbfe0e0 "", buffer_size=4, 
    result=0x495759e0) at ../../gcc4x/gcc/fortran/target-memory.c:486
486           ptr = TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET
(cmp->backend_decl));
(gdb) print cmp->backend_decl
$1 = (tree) 0x0
(gdb) print *cmp
$3 = {name = 0x49830a64 "__c_ptr_c_address", ts = {type = BT_INTEGER, 
    kind = 4, u = {derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, 
    is_c_interop = 1, is_iso_c = 0, f90_type = BT_INTEGER, deferred = 0 '\0'}, 
  attr = {allocatable = 0, dimension = 0, codimension = 0, external = 0, 
    intrinsic = 0, optional = 0, pointer = 0, target = 0, value = 0, 
    volatile_ = 0, temporary = 0, dummy = 0, result = 0, assign = 0, 
    threadprivate = 0, not_always_present = 0, implied_index = 0, 
    subref_array_pointer = 0, proc_pointer = 0, asynchronous = 0, 
    contiguous = 0, class_pointer = 0, save = SAVE_NONE, data = 0, 
    is_protected = 0, use_assoc = 0, use_only = 0, use_rename = 0, 
    imported = 0, host_assoc = 0, in_namelist = 0, in_common = 0, 
    in_equivalence = 0, function = 0, subroutine = 0, procedure = 0, 
    generic = 0, generic_copy = 0, implicit_type = 0, untyped = 0, 
    is_bind_c = 0, extension = 0, is_class = 0, class_ok = 0, vtab = 0, 
    vtype = 0, is_c_interop = 0, is_iso_c = 0, sequence = 0, elemental = 0, 
    pure = 0, recursive = 0, unmaskable = 0, masked = 0, contained = 0, 
    mod_proc = 0, abstract = 0, noreturn = 0, entry = 0, entry_master = 0, 
    mixed_entry_master = 0, always_explicit = 0, referenced = 0, 
    is_main_program = 0, access = ACCESS_UNKNOWN, intent = INTENT_UNKNOWN, 
    flavor = FL_UNKNOWN, if_source = IFSRC_UNKNOWN, proc = PROC_UNKNOWN, 
    cray_pointer = 0, cray_pointee = 0, alloc_comp = 0, pointer_comp = 0, 
    proc_pointer_comp = 0, private_comp = 0, zero_comp = 0, coarray_comp = 0, 
    select_type_temporary = 0, ext_attr = 0, volatile_ns = 0x0, 
    asynchronous_ns = 0x0}, as = 0x0, backend_decl = 0x0, loc = {
    nextc = 0x495740e4, lb = 0x49574080}, initializer = 0x0, next = 0x0, 
  formal = 0x0, formal_ns = 0x0, tb = 0x0}

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2010-12-17 23:15:27 UTC ---
The issues appears to have come into gfortran with pault's
initial commit of Brook's gfc_simplify_transfer.  This
is revision 124759.

Consider 

program z
  use iso_c_binding
  type(c_ptr) m
  m = transfer(12345, m)
end program z

The culprit is the second test in 

  if (!gfc_is_constant_expr (source)
    || (gfc_init_expr_flag && !gfc_is_constant_expr (mold))
    || !gfc_is_constant_expr (size))
    return NULL;

Here, gfc_init_expr_flag = 0 and mold is EXPR_VARIABLE, which
yields !gfc_is_constant_expr (mold) = 1.  Clearly (0 && anything)
is going to be 0. So, gfortran tries to simplify the expression.

If gfc_init_expr_flag is removed, the code compiles.

Anyone know why this flag is needed?

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-12-18 00:01:03 UTC ---
On Fri, Dec 17, 2010 at 11:15:44PM +0000, kargl at gcc dot gnu.org wrote:
> 
> Anyone know why this flag is needed?
> 

Well, the answer is to let simplify_transfer_[34].f90
in the testsuite to compile!  :-)

Given 

   program z
   use iso_c_binding
   type(c_ptr) m
   m = transfer(32512, m)
   m = transfer(32512, C_NULL_PTR)
   end program z

This patch compiles the above.

Index: simplify.c
===================================================================
--- simplify.c  (revision 167949)
+++ simplify.c  (working copy)
@@ -5954,6 +5954,11 @@ gfc_simplify_transfer (gfc_expr *source,
   if (source->expr_type == EXPR_FUNCTION)
     return NULL;

+  if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
+      && mold->ts.type == BT_DERIVED && mold->ts.u.derived
+      && strcmp(mold->ts.u.derived->name, "c_ptr") == 0)
+    return NULL;
+
   /* Calculate the size of the source.  */
   if (source->expr_type == EXPR_ARRAY
       && gfc_array_size (source, &tmp) == FAILURE)

The tree dump looks like

z ()
--More--(74%){
  void * m;

  {
    void * transfer.0;
    integer(kind=8) D.1524;
    integer(kind=8) D.1523;
    static integer(kind=4) C.1522 = 32512;
    integer(kind=8) D.1521;

    D.1521 = 4;
    D.1523 = 8;
    __builtin_memcpy ((void *) &transfer.0, (void *) &C.1522,
       MAX_EXPR <MIN_EXPR <D.1523, D.1521>, 0>);
    m = transfer.0;
  }
  {
    void * transfer.1;
    integer(kind=8) D.1530;
    integer(kind=8) D.1529;
    static void * C.1528 = 0B;
    static integer(kind=4) C.1527 = 32512;
    integer(kind=8) D.1526;

    D.1526 = 4;
    D.1529 = 8;
    __builtin_memcpy ((void *) &transfer.1, (void *) &C.1527,
       MAX_EXPR <MIN_EXPR <D.1529, D.1526>, 0>);
    m = transfer.1;
  }
}

So we are assigning a void * pointer to a void * pointer.  Not
sure this is the desired result.

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-12-18 06:45:19 UTC ---
On Sat, Dec 18, 2010 at 12:01:13AM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> 
> Index: simplify.c
> ===================================================================
> --- simplify.c  (revision 167949)
> +++ simplify.c  (working copy)
> @@ -5954,6 +5954,11 @@ gfc_simplify_transfer (gfc_expr *source,
>    if (source->expr_type == EXPR_FUNCTION)
>      return NULL;
> 
> +  if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
> +      && mold->ts.type == BT_DERIVED && mold->ts.u.derived
> +      && strcmp(mold->ts.u.derived->name, "c_ptr") == 0)
> +    return NULL;
> +
>    /* Calculate the size of the source.  */
>    if (source->expr_type == EXPR_ARRAY
>        && gfc_array_size (source, &tmp) == FAILURE)

Updated patch to hand C_FUNPTR types.

Index: simplify.c
===================================================================
--- simplify.c  (revision 167949)
+++ simplify.c  (working copy)
@@ -5954,6 +5954,12 @@ gfc_simplify_transfer (gfc_expr *source,
   if (source->expr_type == EXPR_FUNCTION)
     return NULL;

+  if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
+      && mold->ts.type == BT_DERIVED && mold->ts.u.derived
+      && (strcmp(mold->ts.u.derived->name, "c_ptr") == 0
+          || strcmp(mold->ts.u.derived->name, "c_funptr") == 0))
+    return NULL;
+
   /* Calculate the size of the source.  */
   if (source->expr_type == EXPR_ARRAY
       && gfc_array_size (source, &tmp) == FAILURE)

I suspect there may be problems with arrays and/or functions that
use these derived types.

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 10:07:33 UTC ---
(In reply to comment #3)
> +  if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
> +      && mold->ts.type == BT_DERIVED && mold->ts.u.derived
> +      && (strcmp(mold->ts.u.derived->name, "c_ptr") == 0
> +          || strcmp(mold->ts.u.derived->name, "c_funptr") == 0))
> +    return NULL;
> +

Won't this cause problems with user-defined types with the same name?
Additionally, I would rather bring C_PTR/C_FUNPTR closer a normal derived type
(which is only in the last step treated specially) than to introduce hacks like
that.

The reason for the crash is that in gfc_interpret_derived the pointer component
of "c_ptr" ("__c_ptr_c_address") has no backend declaration (cmp->backend_decl
== NULL) - and thus "ptr = TREE_INT_CST_LOW (DECL_FIELD_BIT_OFFSET
(cmp->backend_decl))" crashes. Maybe it is sufficient to set it via
gfc_typenode_for_spec in that function.

I think the advantage of fixing this part of the code is that one can simplify
the code at compile time - which is usually preferred to run-time evaluation.

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 15:38:18 UTC ---
Draft patch:

--- a/gcc/fortran/target-memory.c
+++ b/gcc/fortran/target-memory.c
@@ -445,6 +445,21 @@ gfc_interpret_derived (unsigned char *buffer, size_t
buffer_size, gfc_expr *resu
   type = gfc_typenode_for_spec (&result->ts);
   cmp = result->ts.u.derived->components;

+  if (result->ts.u.derived->from_intmod == INTMOD_ISO_C_BINDING
+      && (result->ts.u.derived->intmod_sym_id == ISOCBINDING_PTR
+         || result->ts.u.derived->intmod_sym_id == ISOCBINDING_FUNPTR))
+    {
+      gfc_constructor *c;
+      gfc_expr *e = gfc_get_constant_expr (cmp->ts.type, cmp->ts.kind,
+                                          &result->where); 
+      c = gfc_constructor_append_expr (&result->value.constructor, e, NULL);
+      c->n.component = cmp;
+      gfc_target_interpret_expr (buffer, buffer_size, e);
+      e->ts = result->ts;
+      e->ts.is_iso_c = 1;
+      return int_size_in_bytes (ptr_type_node);
+    }
+
   /* Run through the derived type components.  */
   for (;cmp; cmp = cmp->next)
     {

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 16:21:00 UTC ---
(In reply to comment #5)
> Draft patch:

Which of course does not work ...

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-12-18 17:10:59 UTC ---
On Sat, Dec 18, 2010 at 10:07:51AM +0000, burnus at gcc dot gnu.org wrote:
> 
> --- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 10:07:33 UTC ---
> (In reply to comment #3)
> > +  if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type == EXPR_STRUCTURE)
> > +      && mold->ts.type == BT_DERIVED && mold->ts.u.derived
> > +      && (strcmp(mold->ts.u.derived->name, "c_ptr") == 0
> > +          || strcmp(mold->ts.u.derived->name, "c_funptr") == 0))
> > +    return NULL;
> > +
> 
> Won't this cause problems with user-defined types with the same name?

A check for mold->ts.u.derived->attr.is_iso_c could be added, but
yes I agree that this appears to somewhat hackish.  In fact, the 
patch fails in a interesting way with a new piece of code from
James.

program bug6
   use ISO_C_BINDING
   implicit none
   interface
      function fun()
         use ISO_C_BINDING
         implicit none
         type(C_FUNPTR) fun
      end function fun
   end interface
   type(C_PTR) array(2)
   type(C_FUNPTR) result
   integer(C_INTPTR_T), parameter :: const(*) = [32512,32520]

   result = fun()
   array = transfer([integer(C_INTPTR_T)::32512,32520],array)
!   write(*,*) transfer(result,const)
!   write(*,*) transfer(array,const)
end program bug6

function fun()
   use ISO_C_BINDING
   implicit none
   type(C_FUNPTR) fun
   fun = transfer(32512_C_INTPTR_T,fun)
end function fun 


With this code, mold->ts.type is BT_INTEGER, the backend_decl
is NULL, and mold->ts.u.derived contains the information that
we need.

So, yes, creating a proper backend_decl when C_PTR or C_FUNPTR
is parsed/resolved is probably the correct solution.  Unfortunately,
I don't know how or where to do that. :(

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 20:18:47 UTC ---
Author: burnus
Date: Sat Dec 18 20:18:43 2010
New Revision: 168031

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168031
Log:
2010-12-18  Tobias Burnus  <burnus@net-b.de>

        PR fortran/46974
        * target-memory.c (gfc_interpret_derived): Handle
        * C_PTR/C_FUNPTR.
        * trans-expr.c (gfc_trans_structure_assign): Ditto.
        (gfc_conv_expr): Avoid crashes using non-C_NULL_(FUN)PTR const expr.

2010-12-18  Tobias Burnus  <burnus@net-b.de>

        PR fortran/46974
        * gfortran.dg/c_ptr_tests_16.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/target-memory.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18 20:26:07 UTC ---
FIXED on the trunk (4.6).

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-19 11:24:34 UTC ---
*** Bug 34199 has been marked as a duplicate of this bug. ***

[Bug fortran/46974] ICE with TRANSFER using a C_PTR entity

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-20 21:44:02 UTC ---
Author: burnus
Date: Mon Dec 20 21:43:58 2010
New Revision: 168095

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168095
Log:
2010-12-20  Tobias Burnus  <burnus@net-b.de>

        PR fortran/46974
        * gfortran.dg/c_ptr_tests_16.f90: Fix endian issue.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90