[PATCH] Fix PR61950

[Tobias Burnus]

Hi Richard,

sorry for the belated reply due to spending lazily my time at the sea ...

The patch is okay - and I would even claim that it is obvious.

Regarding the data type, I have no idea why it uses a hard-coded 32bit 
integer instead of a size-type one. I have added it as item to 
https://gcc.gnu.org/wiki/LibgfortranAbiCleanup to change it once we 
break the ABI.

Tobias

PS: I wonder where all the other patch reviewers are, given that quite a 
few patches have accumulated. In particular, I am lacking a patch 
reviewer myself.

Richard Biener wrote:
> The following fixes PR61950 by properly initializing the _size field
> of the static constructor for the vtable init member.  Previously
> gfortran would use a 64bit integer to initialize the 32bit size field
> (not sure why larger aggregates are not considered).
>
> This breaks more sophisticated constant-folding and previously
> inhibited constant folding (which would have worked in this case
> been there no mismatch between initializer and field).
>
> Bootstrap and regtest ongoing on powerpc64-linux-gnu, ok?  I'm not
> considering a backport as it is only a missed optimization there.
>
> Thanks,
> Richard.
>
> 2014-07-31  Richard Biener  <rguenther@suse.de>
>
> 	* trans-expr.c (gfc_conv_structure): Initialize _size with
> 	a value of proper type.
>
> Index: gcc/fortran/trans-expr.c
> ===================================================================
> --- gcc/fortran/trans-expr.c	(revision 213342)
> +++ gcc/fortran/trans-expr.c	(working copy)
> @@ -6260,7 +6260,9 @@ gfc_conv_structure (gfc_se * se, gfc_exp
>         else if (cm->ts.u.derived && strcmp (cm->name, "_size") == 0)
>   	{
>   	  val = TYPE_SIZE_UNIT (gfc_get_derived_type (cm->ts.u.derived));
> -	  CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl, val);
> +	  CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl,
> +				  fold_convert (TREE_TYPE (cm->backend_decl),
> +						val));
>   	}
>         else
>   	{
>