Self-contained reduced test for gfortran 7.2.0 and trunk (8.0)

module gfc_base
 implicit none

 type, public:: gfc_cont_elem_t
  class(*), pointer, private:: value_p=>NULL()
  contains
   procedure, public:: construct_base=>ContElemConstruct
 end type gfc_cont_elem_t

 abstract interface
  function gfc_copy_i(obj,ierr) result(clone)
   class(*), pointer:: clone
   class(*), intent(in), target:: obj
   integer(4), intent(out), optional:: ierr
  end function gfc_copy_i
 end interface

 private ContElemConstruct

contains
 subroutine ContElemConstruct(this,obj,ierr,assoc_only,copy_ctor_f,locked) !`GCC/5.3.0 has a bug with this line
  implicit none
  class(gfc_cont_elem_t), intent(inout):: this 
  class(*), intent(in), target:: obj
  integer(4), intent(out), optional:: ierr
  logical, intent(in), optional:: assoc_only
  procedure(gfc_copy_i), optional:: copy_ctor_f
  logical, intent(in), optional:: locked
 end subroutine ContElemConstruct

end module gfc_base

module gfc_vector
 use gfc_base
 implicit none
 private

 type, extends(gfc_cont_elem_t), public:: vector_elem_t
 contains
  procedure, private:: VectorElemConstruct
 end type vector_elem_t

contains

 subroutine VectorElemConstruct(this,obj,ierr,assoc_only,copy_ctor_f) !`GCC has a bug with this line
  implicit none
  class(vector_elem_t), intent(inout):: this
  class(*), target, intent(in):: obj
  integer(4), intent(out), optional:: ierr
  logical, intent(in), optional:: assoc_only
  procedure(gfc_copy_i), optional:: copy_ctor_f
  integer(4) :: errc

    call this%construct_base(obj,errc,copy_ctor_f=copy_ctor_f)

 end subroutine VectorElemConstruct

end module gfc_vector

Gfortran 6.4.0 and earlier gives the error

  subroutine ContElemConstruct(this,obj,ierr,assoc_only,copy_ctor_f,locked) !`GCC/5.3.0 has a bug with this line
                                                                  1
Error: CLASS variable 'copy_ctor_f' at (1) must be dummy, allocatable or pointer

For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in 78300.

Simplified :


$ cat z1.f90
module m
   type t
   contains
      procedure :: g => s
   end type
contains
   function f(x) result(z)
      class(*), pointer :: z
   end
   subroutine s(x, q)
      class(t) :: x
      procedure(f) :: q
      call x%g(q=q)
   end
end


$ gfortran-9-20180610 -c z1.f90
f951: internal compiler error: Invalid expression in gfc_element_size.
0x65bfef gfc_internal_error(char const*, ...)
        ../../gcc/fortran/error.c:1362
0x6f150b gfc_element_size(gfc_expr*)
        ../../gcc/fortran/target-memory.c:126
0x640228 find_intrinsic_vtab
        ../../gcc/fortran/class.c:2702
0x640228 gfc_find_vtab(gfc_typespec*)
        ../../gcc/fortran/class.c:2845
0x66a6d8 compare_actual_formal
        ../../gcc/fortran/interface.c:2946
0x66c5ae gfc_procedure_use(gfc_symbol*, gfc_actual_arglist**, locus*)
        ../../gcc/fortran/interface.c:3738
0x6cd415 resolve_specific_s0
        ../../gcc/fortran/resolve.c:3457
0x6cd415 resolve_specific_s
        ../../gcc/fortran/resolve.c:3477
0x6cd415 resolve_call
        ../../gcc/fortran/resolve.c:3631
0x6cd9c3 resolve_typebound_call
        ../../gcc/fortran/resolve.c:6232
0x6cba4d resolve_typebound_subroutine
        ../../gcc/fortran/resolve.c:6522
0x6cba4d gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.c:11328
0x6cc95a resolve_codes
        ../../gcc/fortran/resolve.c:16564
0x6cc857 resolve_codes
        ../../gcc/fortran/resolve.c:16548
0x6cca5e gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.c:16599
0x6b6464 gfc_parse_file()
        ../../gcc/fortran/parse.c:6262
0x6fd22f gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:204

(In reply to DIL from comment #2)
> For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in
> 78300.

Are you saying that the exact same bug reappeared here, which had previously been discussed and fixed in PR78300?


(In reply to G. Steinmetz from comment #3)
> Simplified : [...]

Thanks, ICE confirmed/still present.

(In reply to Thomas Schwinge from comment #4)
> (In reply to DIL from comment #2)
> > For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in
> > 78300.
> 
> Are you saying that the exact same bug reappeared here, which had previously
> been discussed and fixed in PR78300?
> 
> 
> (In reply to G. Steinmetz from comment #3)
> > Simplified : [...]
> 
> Thanks, ICE confirmed/still present.

This ICE is still present in gfortran/8.2.0.

(In reply to Thomas Schwinge from comment #4)
> (In reply to DIL from comment #2)
> > For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in
> > 78300.
> 
> Are you saying that the exact same bug reappeared here, which had previously
> been discussed and fixed in PR78300?
> 
> 
> (In reply to G. Steinmetz from comment #3)
> > Simplified : [...]
> 
> Thanks, ICE confirmed/still present.

What I meant in Comment 2 is that this ICE might be related to 78300 that I reported in the past. Both have issues with optional dummy procedure arguments. Sorry for the confusion. This is still an open issue and I still observe this ICE with gfortran/8.2.0.

(In reply to G. Steinmetz from comment #3)

In class.c we have:

Breakpoint 1, find_intrinsic_vtab (ts=0x2474758)
    at ../../trunk/gcc/fortran/class.c:2715
2715                    gfc_element_size (e, &e_size);

(gdb) p e->ts.type
$8 = BT_PROCEDURE

This case is something that is generally not handled.
What is the storage size of procedure (pointers)?

This needs to be added in gfc_element_size or gfc_typenode_for_spec,
and the call in class.c needs to be adjusted accordingly.

(In reply to anlauf from comment #7)
The following patch fixes the ICE:

Index: trans-types.c
===================================================================
--- trans-types.c       (revision 269779)
+++ trans-types.c       (working copy)
@@ -1194,6 +1194,9 @@
            basetype = pfunc_type_node;
        }
        break;
+    case BT_PROCEDURE:
+      basetype = pfunc_type_node;
+      break;
     default:
       gcc_unreachable ();
     }
Index: target-memory.c
===================================================================
--- target-memory.c     (revision 269779)
+++ target-memory.c     (working copy)
@@ -120,6 +120,7 @@
     case BT_CLASS:
     case BT_VOID:
     case BT_ASSUMED:
+    case BT_PROCEDURE:
       {
        /* Determine type size without clobbering the typespec for ISO C
           binding types.  */

However, I do not have a working code sample to run.

(In reply to G. Steinmetz from comment #3)

The test case can be reduced even further:

module m
contains
   function f() result(z)
      class(*), pointer :: z
   end

   recursive subroutine s(q)
      procedure(f) :: q
      call s(q)
   end
end

With the patch in comment 8 all the tests compile and the original test in comment 0 gives ta runtime

 gfc::bank testing status:            0 (PASSED): Performance:    3532045.4736842103     
 gfc::vector testing status:            0 (PASSED): Performance:    2515463.5218254919     
 gfc::list testing status:            0 (PASSED): Performance:    2515463.5218254919     
 gfc::tree testing status:            0 (PASSED): Performance:    1045525.1575901519     
 gfc::dictionary testing status:            0 (PASSED): Performance:    836199.51143490721     
 gfc::graph testing status:            0 (PASSED): Performance:    118470.61398863114     
 Multi-index sort testing status:            0 (PASSED): Performance:    239778.83863299151     
 Dynamic type inferrence slowdown:   0.1258     67109934.2342983   0.1312     67109934.2342983    1.0432470247796064     

> However, I do not have a working code sample to run

The original test is not suitable for the test suite, but the author can probably reduce it.

(In reply to Dominique d'Humieres from comment #10)
> With the patch in comment 8 all the tests compile and the original test in
> comment 0 gives ta runtime
> 
>  gfc::bank testing status:            0 (PASSED): Performance:   
> 3532045.4736842103     
>  gfc::vector testing status:            0 (PASSED): Performance:   
> 2515463.5218254919     
>  gfc::list testing status:            0 (PASSED): Performance:   
> 2515463.5218254919     
>  gfc::tree testing status:            0 (PASSED): Performance:   
> 1045525.1575901519     
>  gfc::dictionary testing status:            0 (PASSED): Performance:   
> 836199.51143490721     
>  gfc::graph testing status:            0 (PASSED): Performance:   
> 118470.61398863114     
>  Multi-index sort testing status:            0 (PASSED): Performance:   
> 239778.83863299151     
>  Dynamic type inferrence slowdown:   0.1258     67109934.2342983   0.1312   
> 67109934.2342983    1.0432470247796064     
> 
> > However, I do not have a working code sample to run
> 
> The original test is not suitable for the test suite, but the author can
> probably reduce it.



Sorry, I am confused, I think Comment 1 already has such a reduced test. At least the what it says there ...

> Sorry, I am confused, I think Comment 1 already has such a reduced test.
> At least the what it says there ...

It is a reduced test for the ICE (as are further reduced tests in comments 3 and 9),
but they do not allow to check that fortran is not producing a wrong code
instead of an ICE.

I understand

> However, I do not have a working code sample to run.

as asking for such a test.

(In reply to Dominique d'Humieres from comment #12)
> > Sorry, I am confused, I think Comment 1 already has such a reduced test.
> > At least the what it says there ...
> 
> It is a reduced test for the ICE (as are further reduced tests in comments 3
> and 9),
> but they do not allow to check that fortran is not producing a wrong code
> instead of an ICE.
> 
> I understand
> 
> > However, I do not have a working code sample to run.
> 
> as asking for such a test.

Exactly.

Taking this PR.  It has some overlap to PR85797 and can probably be fixed
with the same patch.

(In reply to anlauf from comment #13)
> (In reply to Dominique d'Humieres from comment #12)
> > > Sorry, I am confused, I think Comment 1 already has such a reduced test.
> > > At least the what it says there ...
> > 
> > It is a reduced test for the ICE (as are further reduced tests in comments 3
> > and 9),
> > but they do not allow to check that fortran is not producing a wrong code
> > instead of an ICE.
> > 
> > I understand
> > 
> > > However, I do not have a working code sample to run.
> > 
> > as asking for such a test.
> 
> Exactly.
> 
> Taking this PR.  It has some overlap to PR85797 and can probably be fixed
> with the same patch.


Ok, so you are still looking for a single Fortran source file using this feature, namely optional dummy procedure pointers, that would do something non-trivial with them and produce PASS/FAIL output? If yes, then I can try making such a reduced test (if needed). I am just not familiar with GNU test requirements.

(In reply to DIL from comment #14)
> Ok, so you are still looking for a single Fortran source file using this
> feature, namely optional dummy procedure pointers, that would do something
> non-trivial with them and produce PASS/FAIL output? If yes, then I can try
> making such a reduced test (if needed). I am just not familiar with GNU test
> requirements.

Exactly.  Just assume that many thousands of tests are run for
regression testing each time, and productivity of the developers
depends on the turnaround time.

Author: anlauf
Date: Sun Mar 31 18:33:51 2019
New Revision: 270045

URL: https://gcc.gnu.org/viewcvs?rev=270045&root=gcc&view=rev
Log:
2019-03-31  Harald Anlauf  <anlauf@gmx.de>

	PR fortran/83515
	PR fortran/85797
	* trans-types.c (gfc_typenode_for_spec): Handle conversion for
	procedure pointers.
	* target-memory.c (gfc_element_size): Handle size determination
	for procedure pointers.

	PR fortran/83515
	PR fortran/85797
	* gfortran.dg/pr85797.f90: New test.


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

Author: anlauf
Date: Sun Mar 31 19:08:23 2019
New Revision: 270046

URL: https://gcc.gnu.org/viewcvs?rev=270046&root=gcc&view=rev
Log:
2019-03-31  Harald Anlauf  <anlauf@gmx.de>

	PR fortran/83515
	PR fortran/85797
	* trans-types.c (gfc_typenode_for_spec): Handle conversion for
	procedure pointers.
	* target-memory.c (gfc_element_size): Handle size determination
	for procedure pointers.

	PR fortran/83515
	PR fortran/85797
	* gfortran.dg/pr85797.f90: New test.


Added:
    branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr85797.f90
Modified:
    branches/gcc-8-branch/gcc/fortran/ChangeLog
    branches/gcc-8-branch/gcc/fortran/target-memory.c
    branches/gcc-8-branch/gcc/fortran/trans-types.c
    branches/gcc-8-branch/gcc/testsuite/ChangeLog

Author: anlauf
Date: Sun Mar 31 19:21:37 2019
New Revision: 270047

URL: https://gcc.gnu.org/viewcvs?rev=270047&root=gcc&view=rev
Log:
2019-03-31  Harald Anlauf  <anlauf@gmx.de>

	Backport from trunk
	PR fortran/83515
	PR fortran/85797
	* trans-types.c (gfc_typenode_for_spec): Handle conversion for
	procedure pointers.
	* target-memory.c (gfc_element_size): Handle size determination
	for procedure pointers.

	PR fortran/83515
	PR fortran/85797
	* gfortran.dg/pr85797.f90: New test.


Added:
    branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85797.f90
Modified:
    branches/gcc-7-branch/gcc/fortran/ChangeLog
    branches/gcc-7-branch/gcc/fortran/target-memory.c
    branches/gcc-7-branch/gcc/fortran/trans-types.c
    branches/gcc-7-branch/gcc/testsuite/ChangeLog

Fixed on trunk and all open branches (7/8).

Closing, as no reduced run-time testcase was provided.
Please reopen or create a new PR if an issue is found.

Thanks for the report!

(In reply to anlauf from comment #19)
> Fixed on trunk and all open branches (7/8).
> 
> Closing, as no reduced run-time testcase was provided.
> Please reopen or create a new PR if an issue is found.
> 
> Thanks for the report!


Thanks for fixing this bug! Sorry, I have not had time yet to create a reduced non-trivial test case. Would you still like to add it later if I make it? If yes, should I just attach it later to this closed bug report?

(In reply to DIL from comment #20)
> Thanks for fixing this bug! Sorry, I have not had time yet to create a
> reduced non-trivial test case. Would you still like to add it later if I
> make it? If yes, should I just attach it later to this closed bug report?

Just attach it to this PR.  I'll try to take care of it.