User account creation filtered due to spam.
Currently, there are 26 bits for encoding the size
of an object in the array descriptor for 32-bit
targets, because the size is encoded together with
the type, which takes up 6 bits, and dtype is an
index_type (which has 32 bits on a 32-bit target).
It would be nice to have a separate size field.
So an array of the derived type couldn't have more than 2**(32-26) = 64 entries
before overflowing memory with our current scheme, and if this was enlarged the
allowed arrays would be even smaller, but it is certainly true that the sizes of
derived type array elements are limited.
Thomas, isn't the 4.3 branching a good time to work on this? Would you have time for that?
ping: Would you have either an example where this limit is encountered? Wouldn't 4.3 be ideal for that work?
I think this is related to the check in trans-types.c:
if (size && INTEGER_CST_P (size))
if (tree_int_cst_lt (gfc_max_array_element_size, size))
internal_error ("Array element size too big");
i += TREE_INT_CST_LOW (size) << GFC_DTYPE_SIZE_SHIFT;
dtype = build_int_cst (gfc_array_index_type, i);
which is triggered by code such as:
end type t
type(t), allocatable :: x(:)
print *, size(x)
print *, shape(x)
For now, we should simply change the ICE into a standard error.
I'll do this.
Changing this into a normal error leads to double
errors and assorted strangeness.
Unassigning myself for now.
I expect, the array descriptor reform may make this fixable?!
Date: Wed Nov 9 06:57:10 2011
New Revision: 181192
* trans-types.c (gfc_get_dtype): Issue a fatal error instead of
an internal error.
Fixed on trunk.