[Bug fortran/41298] New: wrong-code: Default initializer ignored

[Bug fortran/41298] New: wrong-code: Default initializer ignored

[burnus at gcc dot gnu dot org]

Split off from PR 41293.

The following program should work, i.e. calling "sub" should initialize the
component "gsl_file" with a NULL pointer.


module m
use iso_c_binding
  type, public :: fgsl_file
     type(c_ptr) :: gsl_file = c_null_ptr
  end type fgsl_file
contains
  subroutine sub(file)
    type(fgsl_file), intent(out) :: file
  end subroutine
end module m

use m
type(fgsl_file) :: file
call sub(file)
if(c_associated(file%gsl_file)) call abort()
end


Using the 4.5 trunk (similar dump, same result with 4.3 and 4.4):

sub (struct fgsl_file & restrict file)
{
  if (file != 0)
    {
      {
        struct fgsl_file D.1336;
        struct fgsl_file fgsl_file.0;

        D.1336 = fgsl_file.0;
        *file = fgsl_file.0;
      }
    }
}


-- 
           Summary: wrong-code: Default initializer ignored
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 41293
             nThis:


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

[Bug fortran/41298] wrong-code: Default initializer C_NULL_PTR ignored

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2009-09-08 16:06 -------
Regarding the initialization: Initializing proc pointers and pointers works.

The first time one hits gfc_conv_structure, one has:
  expr->expr_type == EXPR_STRUCTURE
for the type
  expr->ts->u.derived->name == "fgsl_file".
If one drills deeper, one finds another
  expr->value.constructor->expr->expr_type == EXPR_STRUCTURE
this time as expected of the type
  expr->value.constructor->expr->ts->u.derived->name == "c_ptr"
So far so good. Now one just needs to have an EXPR_NULL or EXPR_VARIABLE or
something like that -- but:
  expr->value.constructor->expr->value.constructor->expr == NULL

However, in gfc_conv_structure:
  for (c = expr->value.constructor; c; c = c->next, cm = cm->next)
    {
      if (!c->expr || cm->attr.allocatable)
        continue;

It shouldn't be NULL; if it weren't one could enter gfc_conv_initializer and
could enter there:
  if (expr != NULL && expr->ts.type == BT_DERIVED
      && expr->ts.is_iso_c && expr->ts.u.derived)
    expr = gfc_int_expr (0);

Thus the question is: Why is the last expr == NULL and not EXPR_VARIABLE of
flavour FL_PARAMETER?

 * * *

Another question: Why is there an
  if (file != 0)
I think it should always be true, unless sym is explicitly marked as optional.
Thus the following gives a nanosecond speed up and saves five bytes or so in
the file size (untested):

Index: trans-decl.c
===================================================================
--- trans-decl.c        (revision 151512)
+++ trans-decl.c        (working copy)
@@ -2992,7 +2992,7 @@ gfc_init_default_dt (gfc_symbol * sym, t
   gfc_set_sym_referenced (sym);
   e = gfc_lval_expr_from_sym (sym);
   tmp = gfc_trans_assignment (e, sym->value, false);
-  if (sym->attr.dummy)
+  if (sym->attr.dummy && sym->attr.optional)
     {
       present = gfc_conv_expr_present (sym);
       tmp = build3 (COND_EXPR, TREE_TYPE (tmp), present,
@@ -3030,9 +3030,12 @@ init_intent_out_dt (gfc_symbol * proc_sy
                                             f->sym->backend_decl,
                                             f->sym->as ? f->sym->as->rank :
0);

-           present = gfc_conv_expr_present (f->sym);
-           tmp = build3 (COND_EXPR, TREE_TYPE (tmp), present,
-                         tmp, build_empty_stmt (input_location));
+           if (f->sym->attr.optional)
+             {
+               present = gfc_conv_expr_present (f->sym);
+               tmp = build3 (COND_EXPR, TREE_TYPE (tmp), present,
+                             tmp, build_empty_stmt (input_location));
+             }

            gfc_add_expr_to_block (&fnblock, tmp);
          }


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|wrong-code: Default         |wrong-code: Default
                   |initializer ignored         |initializer C_NULL_PTR
                   |                            |ignored


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

[Bug fortran/41298] wrong-code: Default initializer C_NULL_PTR ignored

[mikael at gcc dot gnu dot org]

------- Comment #2 from mikael at gcc dot gnu dot org  2009-09-09 20:41 -------
(In reply to comment #1)
> Thus the question is: Why is the last expr == NULL and not EXPR_VARIABLE of
> flavour FL_PARAMETER?

gfc_match_rvalue replaces parameters with their values:
    case FL_PARAMETER:
      /* A statement of the form "REAL, parameter :: a(0:10) = 1" will
         end up here.  Unfortunately, sym->value->expr_type is set to 
         EXPR_CONSTANT, and so the if () branch would be followed without
         the !sym->as check.  */
      if (sym->value && sym->value->expr_type != EXPR_ARRAY && !sym->as)
        e = gfc_copy_expr (sym->value);

Then why is the value a NULL expr?
Because that's how we recognise c_null(_fun)?_ptr at resolution time.
See the comment in gen_special_c_interop_ptr:
  /* Create a constructor with no expr, that way we can recognize if the user
     tries to call the structure constructor for one of the iso_c_binding
     derived types during resolution (resolve_structure_cons).  */
  tmp_sym->value->value.constructor = gfc_get_constructor ();
So, it's a feature ;)

Tried a bit, but no idea how to fix it.


-- 

mikael 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         |2009-09-09 20:41:34
               date|                            |


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

[Bug fortran/41298] wrong-code: Default initializer C_NULL_PTR ignored

[jvdelisle at gcc dot gnu dot org]

------- Comment #3 from jvdelisle at gcc dot gnu dot org  2009-09-10 01:08 -------
Features, features, features, always features... :)


-- 


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

[Bug fortran/41298] wrong-code: Default initializer C_NULL_PTR ignored

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2009-09-10 02:43 -------
(In reply to comment #2)
> (In reply to comment #1)
> > Thus the question is: Why is the last expr == NULL and not EXPR_VARIABLE of
> > flavour FL_PARAMETER?
> 
> gfc_match_rvalue replaces parameters with their values:
>     case FL_PARAMETER:
>       /* A statement of the form "REAL, parameter :: a(0:10) = 1" will
>          end up here.  Unfortunately, sym->value->expr_type is set to 
>          EXPR_CONSTANT, and so the if () branch would be followed without
>          the !sym->as check.  */
>       if (sym->value && sym->value->expr_type != EXPR_ARRAY && !sym->as)
>         e = gfc_copy_expr (sym->value);
> 
> Then why is the value a NULL expr?
> Because that's how we recognise c_null(_fun)?_ptr at resolution time.
> See the comment in gen_special_c_interop_ptr:
>   /* Create a constructor with no expr, that way we can recognize if the user
>      tries to call the structure constructor for one of the iso_c_binding
>      derived types during resolution (resolve_structure_cons).  */
>   tmp_sym->value->value.constructor = gfc_get_constructor ();
> So, it's a feature ;)
> 
> Tried a bit, but no idea how to fix it.
> 

I haven't looked at the bug yet, but I would have guessed that we could
use some combination of attr->pointer and ts->iso_c_interop etc to special
case this situation.

There is also the possibility to encapsulate the iso_c_binding stuff in
gfc_typespec into a new struct and add an entity to denote this situation.


-- 


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

[Bug fortran/41298] wrong-code: Default initializer C_NULL_PTR ignored

[dfranke at gcc dot gnu dot org]

------- Comment #5 from dfranke at gcc dot gnu dot org  2009-12-13 16:22 -------
While looking at this one, I found two oddities:
 * There are two similar special-case handlers for ISOCBINDING_NULL_[FUN]PTR, 
   one in trans-expr.c(gfc_conv_initializer), the other in trans-const.c 
   (gfc_conv_constant). They may be redundant?

 * Both these checks create a 'gfc_int_expr(0)' as replacement value, wouldn't
a
   'null_pointer_node' be technically more correct?

I'm out of this one, trans-* is dark magic *uhhh*


-- 

dfranke at gcc dot gnu dot org changed:

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


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

[Bug fortran/41298] wrong-code: Default initializer C_NULL_PTR ignored

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2010-01-06 21:49 -------
Created an attachment (id=19491)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19491&action=view)
Draft patch

Not regtested, need to re-check that the patch is correct, but seems to work
otherwise.


-- 


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

[Bug fortran/41298] wrong-code: Default initializer C_NULL_PTR ignored

[burnus at gcc dot gnu dot org]

------- Comment #8 from burnus at gcc dot gnu dot org  2010-01-09 09:12 -------
FIXED on the trunk (4.5).


-- 

burnus at gcc dot gnu dot org changed:

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


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

[Bug fortran/41298] wrong-code: Default initializer C_NULL_PTR ignored

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2010-01-09 09:12 -------
Subject: Bug 41298

Author: burnus
Date: Sat Jan  9 09:11:53 2010
New Revision: 155755

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

        PR fortran/41298
        * trans-expr.c (gfc_trans_structure_assign): Handle
        c_null_(fun)ptr.
        * symbol.c (gen_special_c_interop_ptr): Add NULL_EXPR
        to the constructor for c_null_(fun)ptr.
        * resolve.c (resolve_structure_cons): Add special case
        for c_null_(fun)ptr.

2010-01-09  Tobias Burnus  <burnus@net-b.de>

        PR fortran/41298
        * gfortran.dg/c_ptr_tests_14.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_14.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/41298] wrong-code: Default initializer C_NULL_PTR ignored

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.5.0


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