Bug 57710 - [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK
Summary: [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: ice-on-valid-code, wrong-code
Depends on:
Blocks:
 
Reported: 2013-06-25 16:59 UTC by Tobias Burnus
Modified: 2020-02-23 15:41 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-06-25 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2013-06-25 16:59:23 UTC 
The following code (minus the IF condition) shows that _vptr is not set for the allocatable component:
        y.x._data = 0B;
there should be - but isn't - additionally: y.x._vptr = &__vtab_m_T;


Additionally, the test case as is (with IF condition), currently crashes with:

internal compiler error: in gfc_conv_component_ref, at fortran/trans-expr.c:1654
   if (.not. same_type_as(y%x, z)) call abort ()
 ^
0x632ce2 gfc_conv_component_ref
        ../../gcc/fortran/trans-expr.c:1654
0x63fc89 gfc_conv_variable
        ../../gcc/fortran/trans-expr.c:1921


module m
  type t
  end type t
  type t2
    integer :: ii
    class(t), allocatable :: x
  end type t2
contains
  subroutine fini(x)
     type(t) :: x
  end subroutine fini
end module m

use m
block
  type(t) :: z
  type(t2) :: y
  y%ii = 123
  if (.not. same_type_as(y%x, z)) call abort ()
end block
end
Comment 1 Dominique d'Humieres 2013-06-25 17:11:03 UTC 
Confirmed.
Comment 2 janus 2013-07-31 07:46:19 UTC 
(In reply to Tobias Burnus from comment #0)
> The following code (minus the IF condition) shows that _vptr is not set for
> the allocatable component:
>         y.x._data = 0B;
> there should be - but isn't - additionally: y.x._vptr = &__vtab_m_T;

Without the BLOCK, the dump shows:

  static struct t2 y = {.x={._vptr=&__vtab_m_T}};

  y.x._data = 0B;
  y.ii = 123;

while with the BLOCK one gets:

    struct t2 y;

    try
      {
        y.x._data = 0B;
        y.ii = 123;
        L.1:;
      }

Can't we do a 'static' initialization (of _vptr *and* _data) in both cases? As in

  struct t2 y = {.x={._vptr=&__vtab_m_T,._data = 0B}}

For this gfc_class_null_initializer (from class.c) could be used ...
Comment 3 janus 2013-07-31 07:51:52 UTC 
(In reply to Tobias Burnus from comment #0)
> Additionally, the test case as is (with IF condition), currently crashes
> with:
> 
> internal compiler error: in gfc_conv_component_ref, at
> fortran/trans-expr.c:1654

Also the ICE occurs only with the BLOCK construct. Slightly reduced test case:

module m
  type t
  end type
  type t2
    class(t), allocatable :: x
  end type
end module

use m
type(t) :: z
block
  type(t2) :: y
  if (.not. same_type_as(y%x, z)) call abort ()
end block
end
Comment 4 janus 2013-07-31 19:15:49 UTC 
(In reply to janus from comment #2)
> Can't we do a 'static' initialization (of _vptr *and* _data) in both cases?
> As in
> 
>   struct t2 y = {.x={._vptr=&__vtab_m_T,._data = 0B}}
> 
> For this gfc_class_null_initializer (from class.c) could be used ...

... we would just have to enable this for the BLOCK case in gfc_get_symbol decl. However, I'm not sure if this is really the way to go.

Otherwise, one should do the (non-static) initialization of the _vptr via gfc_nullify_alloc_comp.
Comment 5 Tobias Burnus 2013-08-01 20:40:03 UTC 
(In reply to janus from comment #2)
> Can't we do a 'static' initialization (of _vptr *and* _data) in both cases?

Well, you need to free and finalize the variable - hence, it cannot be static.
Comment 6 Paul Thomas 2020-02-23 15:41:30 UTC 
Fixed in r10-6801-g61c8d9e4e5f540501eaa98aae1d6c74bde7d4299

Thanks for the report.

Paul