Re: [Patch, fortran] PR24789 - ICE when assigning to array of strings

[Paul Thomas <paulthomas2 at wanadoo dot fr>]

Jakub,

> Setting TYPE_SIZE_UNIT looks wrong to me, there is TYPE_SIZE, TYPE_DOMAIN
> of the array type etc. too.
The TYPE_SIZE_UNIT is what was missing.  Look you here:

[prt@localhost trunk]# grep TYPE_SIZE_UNIT gcc/fortran/*.c
gcc/fortran/trans-array.c:                      TYPE_SIZE_UNIT 
(gfc_get_element_ type (type)));
gcc/fortran/trans-array.c:  size = TYPE_SIZE_UNIT (gfc_get_element_type 
(TREE_TY PE (desc)));
gcc/fortran/trans-array.c:            size = TREE_INT_CST_LOW 
(TYPE_SIZE_UNIT (t ype));
gcc/fortran/trans-array.c:  tmp = TYPE_SIZE_UNIT (gfc_get_element_type 
(type));
gcc/fortran/trans-array.c:  tmp = TYPE_SIZE_UNIT (gfc_get_element_type 
(type));
gcc/fortran/trans-array.c:        loop.temp_ss->string_length = 
TYPE_SIZE_UNIT ( loop.temp_ss->data.temp.type);
gcc/fortran/trans-common.c:      tree size = TYPE_SIZE_UNIT (union_type);

===================These are mine==============
gcc/fortran/trans-decl.c:             if (TYPE_SIZE_UNIT (etype) == 
NULL_TREE)
gcc/fortran/trans-decl.c:                 tmp = TYPE_SIZE_UNIT 
(gfc_character1_t ype_node);
gcc/fortran/trans-decl.c:                 TYPE_SIZE_UNIT (etype) = tmp;
===============================================

gcc/fortran/trans-io.c:  pad_size = 16 * TREE_INT_CST_LOW 
(TYPE_SIZE_UNIT (pchar _type_node));
gcc/fortran/trans-io.c:  pad_size += 32 * TREE_INT_CST_LOW 
(TYPE_SIZE_UNIT (inte ger_type_node));
gcc/fortran/trans-io.c:  tmp = TYPE_SIZE_UNIT (gfc_get_element_type (type));
gcc/fortran/trans-stmt.c:  unit = TYPE_SIZE_UNIT (type);
gcc/fortran/trans-stmt.c:                             TYPE_SIZE_UNIT 
(smallest_b oolean_type_node));
gcc/fortran/trans-stmt.c:         tmp = TYPE_SIZE_UNIT (TREE_TYPE 
(TREE_TYPE (se .expr)));
gcc/fortran/trans-types.c:  size = TYPE_SIZE_UNIT (etype);

most immediately, it was

00582     size = fold_build2 (MULT_EXPR, gfc_array_index_type, size,
00583                         TYPE_SIZE_UNIT (gfc_get_element_type(type)));
00584 

in gfc_trans_allocate_temp_array that was causing the segfaults.  I just 
gave it what it wanted.

There are no appearances of TYPE_SIZE in gfortran and for TYPE_DOMAIN

gcc/fortran/trans-array.c:      tmp = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
gcc/fortran/trans-const.c:    se->string_length = TYPE_MAX_VALUE 
(TYPE_DOMAIN (TREE_TYPE (se->expr)));
gcc/fortran/trans-expr.c:  len = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
gcc/fortran/trans-expr.c:          arglen = TYPE_MAX_VALUE (TYPE_DOMAIN 
(type));
gcc/fortran/trans-expr.c:  se->string_length = TYPE_MAX_VALUE 
(TYPE_DOMAIN (TREE_TYPE (se->expr)));
gcc/fortran/trans-io.c:   arg2 = TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE 
(tmp)));
gcc/fortran/trans-types.c:  TYPE_DOMAIN (type) = range;

I guess that I will have to study this some more.  In the mean time, my 
patch responds directly to the cause of the problem.  I would be the 
first to agree that there is underlying stuff to deal with.

I suggest that if there are no regressions reported, due to this, in the 
next day or so, that I commit to 4.1 and 4.0, on the understanding that 
we come back to array representation and sort out the mess of pointers 
and aliassing in the longer term.  Perhaps I should raise an RH bug report?

> Can you please look at the gomp branch where I revamped this area quite a
> lot (because OpenMP middle-end relies on accurate variable length array
> sizes)?
> Especially the
> http://gcc.gnu.org/ml/fortran/2005-10/msg00469.html
> and
> http://gcc.gnu.org/ml/fortran/2005-11/msg00208.html
> changes.
Gladly, if you think that it will help.

> IMHO the type should be created already with the proper length known
> (whether it is the hidden _foo length PARM_DECL, or .foo artificial variable
> that is initialized in gfc_trans_deferred_vars for CHARACTER variables
> and dummy arguments and return vars), or for array types the various
> artificial vars initialized in gfc_trans_deferred_vars as well (except
> for assumed size arrays which of course don't have known size).
I would agree with that.  dummy pointer arrays are picked out for 
specific non-treatment.

> I can distill non-OpenMP dependent changes from the gomp branch soon
> for review if there would be interest in that.
>
> 	
That would be very useful.

Cheers

Paul