Janus Weil wrote:
ping!
Sorry, I currently have only a shaky internet connection and also no
access to my development system.
Looking at gfc_class_initializer, I have the impression that it does not
handle initialization of unlimited polymorphic variables/components. I
don't know whether initialization is permitted, but my feeling is that
the following should work:
type t
class(*), pointer :: x
end type t
type(t), target :: y
integer,target :: z
type(t) :: x = t(y)
type(t) :: x = t(z)
class(*), pointer :: a => y
And I have the feeling that it is not correctly treated - but I might be
wrong. (Note to the example above: I believe "t(y)" is a valid structure
constructor, which is not yet supported. But again, I might be wrong
about either.)
Regarding the example: Does it now work when the target and the pointer
are in the same scoping unit? Or does one still need to place the
targets into the module?
2013/7/30 Janus Weil <ja...@gcc.gnu.org>:
The attached update fixes it, and thus should hopefully be
regression-free. It also renames 'gfc_class_null_initializer' to
'gfc_class_initializer', since it now also does other initializations
beside EXPR_NULL.
Will do another regtest to make sure it's clean.
No failures observed. As a test case I'm using now Tobias' extended
version (attached). New ChangeLog below.
Well, the test case does not check whether it works. You either need to
check the dump - or you need to use dg-do run.
Tobias
2013-07-30 Janus Weil <ja...@gcc.gnu.org>
PR fortran/57306
* class.c (gfc_class_null_initializer): Rename to
'gfc_class_initializer'. Treat non-NULL init-exprs.
* gfortran.h (gfc_class_null_initializer): Update prototype.
* trans-decl.c (gfc_get_symbol_decl): Treat class pointers.
* trans-expr.c (gfc_conv_initializer): Ditto.
(gfc_trans_subcomponent_assign): Renamed gfc_class_null_initializer.
2013-07-30 Janus Weil <ja...@gcc.gnu.org>
PR fortran/57306
* gfortran.dg/pointer_init_8.f90: New.
