Re: [Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

[Paul Richard Thomas]

Committed to 7-branch as revision 254429.


Paul

On 5 November 2017 at 12:44, Paul Richard Thomas
 wrote:
> Hi Andre and Thomas,
>
> Thanks for looking at this.
>
> I left the condition as it is because it is the same practice as all
> sorts of other parts of gfortran. That said, Thomas's suggestion is I
> think the right one.
>
> Committed revision as revision 254427. 7-branch will come later.
>
> Regards
>
> Paul
>
> On 4 November 2017 at 18:35, Thomas Koenig  wrote:
>> Hi Andre,
>>
>>> Shouldn't that better be
>>>
>>> if ((gfc_option.allow_std & GFC_STD_F2003) > 0
>>
>>
>> I think that
>>
>> if ((gfc_option.allow_std & GFC_STD_F2003)
>>
>> would be better - the allow_std field is signed, and
>> things could get hariy if we ever have close to 32
>> standards we would like to support.
>>
>> Hm, come to think of it, is there a special reason to keep
>> this signed, or could we just change it to unsigned?
>>
>> Regards
>>
>> Thomas
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

[Paul Richard Thomas]

Hi Andre and Thomas,

Thanks for looking at this.

I left the condition as it is because it is the same practice as all
sorts of other parts of gfortran. That said, Thomas's suggestion is I
think the right one.

Committed revision as revision 254427. 7-branch will come later.

Regards

Paul

On 4 November 2017 at 18:35, Thomas Koenig  wrote:
> Hi Andre,
>
>> Shouldn't that better be
>>
>> if ((gfc_option.allow_std & GFC_STD_F2003) > 0
>
>
> I think that
>
> if ((gfc_option.allow_std & GFC_STD_F2003)
>
> would be better - the allow_std field is signed, and
> things could get hariy if we ever have close to 32
> standards we would like to support.
>
> Hm, come to think of it, is there a special reason to keep
> this signed, or could we just change it to unsigned?
>
> Regards
>
> Thomas



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

[Thomas Koenig]

Hi Andre,


Shouldn't that better be

if ((gfc_option.allow_std & GFC_STD_F2003) > 0


I think that

if ((gfc_option.allow_std & GFC_STD_F2003)

would be better - the allow_std field is signed, and
things could get hariy if we ever have close to 32
standards we would like to support.

Hm, come to think of it, is there a special reason to keep
this signed, or could we just change it to unsigned?

Regards

Thomas

Re: [Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

[Andre Vehreschild]

Hi Paul,

On Thu, 2 Nov 2017 20:11:29 +
Paul Richard Thomas  wrote:

> *** resolve_fl_derived (gfc_symbol *sym)
> *** 14075,14080 
> --- 14078,14097 
> if (!resolve_typebound_procedures (sym))
>   return false;
> 
> +   /* Generate module vtables subject to their accessibility and their not
> +  being vtables or pdt templates. If this is not done class declarations
> +  in external procedures wind up with their own version and so SELECT
> TYPE
> +  fails because the vptrs do not have the same address.  */
> +   if (gfc_option.allow_std & GFC_STD_F2003

Shouldn't that better be

   if ((gfc_option.allow_std & GFC_STD_F2003) > 0

? I regularly fall on my nose because of the compiler binding this not as
expected. 

> +   && sym->ns->proc_name
> +   && sym->ns->proc_name->attr.flavor == FL_MODULE
> +   && sym->attr.access != ACCESS_PRIVATE
> +   && !(sym->attr.use_assoc || sym->attr.vtype ||
> sym->attr.pdt_template))
> + {
> +   gfc_symbol *vtab = gfc_find_derived_vtab (sym);
> +   gfc_set_sym_referenced (vtab);
> + }
> +
> return true;
>   }

Besides that I think this is OK.

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

[Paul Richard Thomas]

Dear All,

Please find attached the revised version of the patch following my
late realizations in yesterday's submission.

Cheers

Paul


On 1 November 2017 at 18:22, Paul Richard Thomas
 wrote:
> Dear All,
>
> This patch is adequately described by the comment in the second chunk
> applied to resolve.c.
>
> Note, however, that the 'unconditionally' is promptly undermined by
> the subsequent conditions. I will change the adjective appropriately.
> In writing this, I have just realised that access=private need not
> have a vtable generated unless it is required for a class within the
> module. I will make it so a regtest once more.
>
> Some of the increases in counts in the tree dumps look alarming. They
> are however just a reflection of the number of derived types in some
> of the tests and are due to the auxiliary vtable functions.
>
> Bootstrapped and regtested on FC23/x86_64 - OK for trunk and then 7- branch?
>
> Paul
>
> 2017-11-01  Paul Thomas  
>
> PR fortran/81447
> PR fortran/82783
> * resolve.c (resolve_component): There is no need to resolve
> the components of a use associated vtype.
> (resolve_fl_derived): Unconditionally generate a vtable for any
> module derived type, as long as the standard is F2003 or later
> and it is not a vtype or a PDT template.
>
> 2017-11-01  Paul Thomas  
>
> PR fortran/81447
> * gfortran.dg/class_65.f90: New test.
> * gfortran.dg/alloc_comp_basics_1.f90: Increase builtin_free
> count from 18 to 21.
> * gfortran.dg/allocatable_scalar_9.f90: Increase builtin_free
> count from 32 to 54.
> * gfortran.dg/auto_dealloc_1.f90: Increase builtin_free
> count from 4 to 10.
> * gfortran.dg/coarray_lib_realloc_1.f90: Increase builtin_free
> count from 3 to 6. Likewise _gfortran_caf_deregister from 2 to
> 3, builtin_malloc from 1 to 4 and builtin_memcpy|= MEM from
> 2 to 5.
> * gfortran.dg/finalize_28.f90: Increase builtin_free
> count from 3 to 6.
> * gfortran.dg/move_alloc_15.f90: Increase builtin_free and
> builtin_malloc counts from 11 to 14.
> * gfortran.dg/typebound_proc_27.f03: Increase builtin_free
> count from 7 to 10. Likewise builtin_malloc from 12 to 15.



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 254300)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_component (gfc_component *c, gfc
*** 13496,13501 
--- 13496,13504 
if (c->attr.artificial)
  return true;

+   if (sym->attr.vtype && sym->attr.use_assoc)
+ return true;
+
/* F2008, C442.  */
if ((!sym->attr.is_class || c != sym->components)
&& c->attr.codimension
*** resolve_fl_derived (gfc_symbol *sym)
*** 14075,14080 
--- 14078,14097 
if (!resolve_typebound_procedures (sym))
  return false;

+   /* Generate module vtables subject to their accessibility and their not
+  being vtables or pdt templates. If this is not done class declarations
+  in external procedures wind up with their own version and so SELECT TYPE
+  fails because the vptrs do not have the same address.  */
+   if (gfc_option.allow_std & GFC_STD_F2003
+   && sym->ns->proc_name
+   && sym->ns->proc_name->attr.flavor == FL_MODULE
+   && sym->attr.access != ACCESS_PRIVATE
+   && !(sym->attr.use_assoc || sym->attr.vtype || sym->attr.pdt_template))
+ {
+   gfc_symbol *vtab = gfc_find_derived_vtab (sym);
+   gfc_set_sym_referenced (vtab);
+ }
+
return true;
  }

Index: gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90
===
*** gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90   (revision 254300)
--- gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90   (working copy)
*** contains
*** 141,144 
  end subroutine check_alloc2

  end program alloc
! ! { dg-final { scan-tree-dump-times "builtin_free" 18 "original" } }
--- 141,144 
  end subroutine check_alloc2

  end program alloc
! ! { dg-final { scan-tree-dump-times "builtin_free" 21 "original" } }
Index: gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90
===
*** gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90  (revision 254300)
--- gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90  (working copy)
***
*** 5,17 
  !
  ! Contributed by Tobias Burnus 

! module m
! type st
!   integer , allocatable :: a1
! end type st
! type at
!   integer , allocatable :: a2(:)
! end type at

  type t1
type(st), allocatable :: b1
--- 5,17 
  !
  ! Contributed by Tobias Burnus 

! module m
! type st
!   integer , allocatable :: 

[Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

[Paul Richard Thomas]

Dear All,

This patch is adequately described by the comment in the second chunk
applied to resolve.c.

Note, however, that the 'unconditionally' is promptly undermined by
the subsequent conditions. I will change the adjective appropriately.
In writing this, I have just realised that access=private need not
have a vtable generated unless it is required for a class within the
module. I will make it so a regtest once more.

Some of the increases in counts in the tree dumps look alarming. They
are however just a reflection of the number of derived types in some
of the tests and are due to the auxiliary vtable functions.

Bootstrapped and regtested on FC23/x86_64 - OK for trunk and then 7- branch?

Paul

2017-11-01  Paul Thomas  

PR fortran/81447
PR fortran/82783
* resolve.c (resolve_component): There is no need to resolve
the components of a use associated vtype.
(resolve_fl_derived): Unconditionally generate a vtable for any
module derived type, as long as the standard is F2003 or later
and it is not a vtype or a PDT template.

2017-11-01  Paul Thomas  

PR fortran/81447
* gfortran.dg/class_65.f90: New test.
* gfortran.dg/alloc_comp_basics_1.f90: Increase builtin_free
count from 18 to 21.
* gfortran.dg/allocatable_scalar_9.f90: Increase builtin_free
count from 32 to 54.
* gfortran.dg/auto_dealloc_1.f90: Increase builtin_free
count from 4 to 10.
* gfortran.dg/coarray_lib_realloc_1.f90: Increase builtin_free
count from 3 to 6. Likewise _gfortran_caf_deregister from 2 to
3, builtin_malloc from 1 to 4 and builtin_memcpy|= MEM from
2 to 5.
* gfortran.dg/finalize_28.f90: Increase builtin_free
count from 3 to 6.
* gfortran.dg/move_alloc_15.f90: Increase builtin_free and
builtin_malloc counts from 11 to 14.
* gfortran.dg/typebound_proc_27.f03: Increase builtin_free
count from 7 to 10. Likewise builtin_malloc from 12 to 15.
Index: gcc/fortran/match.c
===
*** gcc/fortran/match.c (revision 254300)
--- gcc/fortran/match.c (working copy)
*** gfc_match_allocate (void)
*** 4010,4019 
  
  /* TODO understand why this error does not appear but, instead,
 the derived type is caught as a variable in primary.c.  */
! if (gfc_spec_list_type (type_param_spec_list, NULL) != SPEC_EXPLICIT)
{
  gfc_error ("The type parameter spec list in the type-spec at "
!"%L cannot contain ASSUMED or DEFERRED parameters",
 _locus);
  goto cleanup;
}
--- 4010,4019 
  
  /* TODO understand why this error does not appear but, instead,
 the derived type is caught as a variable in primary.c.  */
! if (gfc_spec_list_type (type_param_spec_list, NULL) == SPEC_DEFERRED)
{
  gfc_error ("The type parameter spec list in the type-spec at "
!"%L cannot contain DEFERRED parameters",
 _locus);
  goto cleanup;
}
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 254300)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_component (gfc_component *c, gfc
*** 13496,13501 
--- 13496,13504 
if (c->attr.artificial)
  return true;
  
+   if (sym->attr.vtype && sym->attr.use_assoc)
+ return true;
+ 
/* F2008, C442.  */
if ((!sym->attr.is_class || c != sym->components)
&& c->attr.codimension
*** resolve_fl_derived (gfc_symbol *sym)
*** 14075,14080 
--- 14078,14096 
if (!resolve_typebound_procedures (sym))
  return false;
  
+   /* Generate module vtables unconditionally. If this is not done
+  class declarations in external procedures wind up with their
+  own version and so SELECT TYPE fails because the vptrs do not
+  have the same address.  */
+   if (gfc_option.allow_std & GFC_STD_F2003
+   && sym->ns->proc_name
+   && sym->ns->proc_name->attr.flavor == FL_MODULE
+   && !(sym->attr.use_assoc || sym->attr.vtype || sym->attr.pdt_template))
+ {
+   gfc_symbol *vtab = gfc_find_derived_vtab (sym);
+   gfc_set_sym_referenced (vtab);
+ }
+ 
return true;
  }
  
Index: gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90
===
*** gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90   (revision 254300)
--- gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90   (working copy)
*** contains
*** 141,144 
  end subroutine check_alloc2
  
  end program alloc
! ! { dg-final { scan-tree-dump-times "builtin_free" 18 "original" } }
--- 141,144 
  end subroutine check_alloc2
  
  end program alloc
! ! { dg-final {