[Patch, fortran] PR24311 - MERGE with character arguments causing ICE in IO statements.

[Paul Thomas]

Tobi,

>Paul Thomas wrote:
>  
>
>>+   /* Merge is unusual in that tsource can be a character constant, whose typespec
>>+      is transferred to that of the output array.  This will not have had a charlen
>>+      created, so it is done here to prevent the middle-end being hit by an
>>+      apparently incomplete character array(PR24311).  */
>>    
>>
>
>Wouldn't this be true for all other array transformational functions as well?
>
>  
>
What is was trying to say, in a rather inarticulate fashion, is that 
other transformational functions take an existing array and modify it's 
rank or shape, whereas merge takes the shape of the logical matrix, arg 
#3, and gives it the type of the first two arguments.  I guess that 
another difference is that the other transformational functions are all 
library, so that the expression gets evaluated in gfc_conv_expr before 
the function call is built and the character length added to the typespec.

>>+   if (tsource->expr_type == EXPR_CONSTANT
>>+ 	&& tsource->ts.type == BT_CHARACTER
>>+ 	&& tsource->ts.cl == NULL)
>>+     {
>>+       tsource->ts.cl = gfc_get_charlen ();
>>+       tsource->ts.cl->next = gfc_current_ns->cl_list;
>>+       gfc_current_ns->cl_list = tsource->ts.cl;
>>+       tsource->ts.cl->length = gfc_int_expr (tsource->value.character.length);
>>+     }
>>    
>>
>
>Shouldn't this have happened much earlier?  I.e. expr->ts.cl->length should be
>expr->value.character.length, at least after constant substrings have been
>evaluated?
>  
>
 From my first run through this code, which is unfamiliar to me, it 
seems not.  To my surprise, there is no sign of this happening for 
MERGE, from parsing to resolve_merge.

I will take a look at some of the other transformationl functions and 
get to the bottom of why they work and merge does not.

Cheers

Paul