Patchwork [Fortran] PR41600 - fix ICE with type conversion in default initializer

login
register
mail settings
Submitter Tobias Burnus
Date Jan. 22, 2012, 4:15 p.m.
Message ID <4F1C3617.9060902@net-b.de>
Download mbox | patch
Permalink /patch/137246/
State New
Headers show

Comments

Tobias Burnus - Jan. 22, 2012, 4:15 p.m.
Dear all,

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 thus part 
of of the issue of the PR.

Build and regtested on x86-64-linux.
OK for the trunk?

Tobias
Tobias Burnus - Jan. 22, 2012, 4:53 p.m.
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
Tobias Burnus - Jan. 28, 2012, 1:18 p.m.
* ping *

http://gcc.gnu.org/ml/fortran/2012-01/msg00197.html

On 22 January 2012, Tobias Burnus wrote:
> Dear all,
>
> 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 thus part 
> of of the issue of the PR.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias

Patch

2012-01-22  Tobias Burnus  <burnus@net-b.de>

	PR fortran/41600
	* expr.c (gfc_default_initializer): Convert the values if
	the type does not match.

2012-01-22  Tobias Burnus  <burnus@net-b.de>

	PR fortran/41600
	* gfortran.dg/default_initialization_6.f90: New.

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 7cea780..8565b81 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3774,7 +3780,13 @@  gfc_default_initializer (gfc_typespec *ts)
       gfc_constructor *ctor = gfc_constructor_get();
 
       if (comp->initializer)
-	ctor->expr = gfc_copy_expr (comp->initializer);
+	{
+	  ctor->expr = gfc_copy_expr (comp->initializer);
+	  if ((comp->ts.type != comp->initializer->ts.type
+	       || comp->ts.kind != comp->initializer->ts.kind)
+	      && !comp->attr.pointer && !comp->attr.proc_pointer)
+	    gfc_convert_type_warn (ctor->expr, &comp->ts, 2, false);
+	}
 
       if (comp->attr.allocatable
 	  || (comp->ts.type == BT_CLASS && CLASS_DATA (comp)->attr.allocatable))
--- /dev/null	2012-01-22 08:37:16.127677872 +0100
+++ gcc/gcc/testsuite/gfortran.dg/default_initialization_6.f90	2012-01-22 15:46:16.000000000 +0100
@@ -0,0 +1,11 @@ 
+! { dg-do compile }
+!
+! PR fortran/41600
+!
+  implicit none
+  type t
+     integer :: X = -999.0
+  end type t
+  class(t), allocatable :: y(:)
+  allocate (t :: y(1))
+end