[Bug fortran/35983] C_LOC in derived type constructor gives weird result

mikael dot morin at tele2 dot fr gcc-bugzilla@gcc.gnu.org
Wed Nov 5 11:45:00 GMT 2008



------- Comment #2 from mikael dot morin at tele2 dot fr  2008-11-05 11:43 -------
There is a reset of the expression to NULL_EXPR in case we encounter c_null_ptr
or c_null_funptr. 
However, the if conditions for this relies on the is_iso_c attribute, which is
the case of c_loc. 
This patch changes this behavior by relying on the symtree names instead. 

Index: trans-expr.c
===================================================================
--- trans-expr.c        (révision 141583)
+++ trans-expr.c        (copie de travail)
@@ -3689,15 +3682,16 @@ gfc_trans_structure_assign (tree dest, gfc_expr *
     {
       /* Skip absent members in default initializers.  */
       if (!c->expr)
-        continue;
+       continue;

       /* Update the type/kind of the expression if it represents either
         C_NULL_PTR or C_NULL_FUNPTR.  This is done here because this may
         be the first place reached for initializing output variables that
         have components of type C_PTR/C_FUNPTR that are initialized.  */
-      if (c->expr->ts.type == BT_DERIVED && c->expr->ts.derived
-         && c->expr->ts.derived->attr.is_iso_c)
-        {
+      if (c->expr->symtree && c->expr->symtree->name
+         && (!strcmp ("c_null_ptr", c->expr->symtree->name)
+             || !strcmp ("c_null_funptr", c->expr->symtree->name)))
+       {
          c->expr->expr_type = EXPR_NULL;
          c->expr->ts.type = c->expr->ts.derived->ts.type;
          c->expr->ts.f90_type = c->expr->ts.derived->ts.f90_type;

With this patch alone, I still get wrong-code though (pointer uninitialized
instead of nullified). 
I've had to revert this patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35150#c7
to have it working. 

There is only one regression, c_loc_tests_12.f03. 
That one is expected, and we are back at PR35150. 
I looked at that one too, but I must admit I'm at least as confused as FX when
he fixed it. 
If some middle-end gurus could take a look/give some tips there...


-- 


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



More information about the Gcc-bugs mailing list