Tobias Burnus wrote:
the middle end does not like to fold_convert a real number to an
integer, but gfortran does not type-convert the expressions of
initialization expressions. This patch fixes the issue
And Tobias Schlüter wrote in the PR:
(In reply to comment #3)
+ if (comp->ts.type != comp->initializer->ts.type
+ || comp->ts.kind != comp->initializer->ts.kind)
+ gfc_convert_type_warn (ctor->expr,&comp->ts, 2, false);
+ }
Isn't gfc_compare_types() more appropriate or are derived types not allowed?
Well, the function gfc_default_initializer should only be reachable if
the LHS and the RHS are type compatible. While, "integer = 4.8" and
"real = cmplx(1.0, 3.0)" are possible, you cannot have "type(t2) :: x =
t1()". Thus, I sincerely hope that such incompatible types are diagnosed
before. Hence, doing this simple test should be sufficient.
* * *
Having said that, the following program compiles without any error -
until one tries to use "my_t". (Now filled as PR51945.)
type t
integer :: i = 3
end type t
type, extends(t) :: t2
end type t2
type :: t3
integer :: i = 78
end type t3
type my_t
type(t) :: x = t() ! OK
type(t) :: y = t2() ! Invalid
type(t) :: z = t3() ! Invalid
end type my_t
! type(my_t) :: a
end
Tobias