2011-11-11 Tobias Burnus <burnus@net-b.de>
PR fortran/51073
* trans-decl.c (generate_coarray_sym_init): Handle zero-sized arrays.
@@ -4234,12 +4238,16 @@ generate_coarray_sym_init (gfc_symbol *sym)
size = TYPE_SIZE_UNIT (gfc_get_element_type (TREE_TYPE (decl)));
+ /* Ensure that we do not have size=0 for zero-sized arrays. */
+ size = fold_build2_loc (input_location, MAX_EXPR, size_type_node,
+ fold_convert (size_type_node, size),
+ build_int_cst (size_type_node, 1));
+
if (GFC_TYPE_ARRAY_RANK (TREE_TYPE (decl)))
{
tmp = GFC_TYPE_ARRAY_SIZE (TREE_TYPE (decl));
size = fold_build2_loc (input_location, MULT_EXPR, size_type_node,
- fold_convert (size_type_node, tmp),
- fold_convert (size_type_node, size));
+ fold_convert (size_type_node, tmp), size);
}
gcc_assert (GFC_TYPE_ARRAY_CAF_TOKEN (TREE_TYPE (decl)) != NULL_TREE);
Dear all, attached one patches for issues found by Joel when testing gfortran on RTEMS. Coarrays with -fcoarray=lib: For zero-sized static ("save") coarray arrays, we should allocate a single byte rather than 0 bytes as "ptr = malloc (0)" might return either NULL or a unique pointer. If it returns 0, we regard it as error condition and abort. The patch does the same we do for nonstatic variables: It allocates a single byte in this case; as it is done in the front-end and as it is a compile-time constant, there is no performance problem ;-) Example (compile with -fcoarray=lib and search for _gfortran_caf_register): integer, save :: caf(1:0)[*] print *, size(caf) end The existing test case is gfortran.dg/coarray/lock_1.f90 which contains a zero-component derived type. [There is another issue related to backtracing support: libgfortran assumes that getenv("PATH") is set. While that's true for most systems, it is not true for all - and if I understood RTEMS correctly, it also only allows a single process (but multiple threads) such that setting the PATH is pointless and wastes memory. However, Janne wants to take care of that patch.] Build and regtested on x86-64-Linux. OK for the trunk? Tobias PS: The last regression count I saw for RTEMS is as follows (mips-unknown-rtems4.11). The numbers look really good: === gfortran Summary === # of expected passes 38236 # of unexpected failures 277 # of expected failures 50 # of unsupported tests 374 If I look the log, we have ~22 failures due to chmod (PR36755), ~8 failures due to pattern matching of the output - I do not understand why, for me the pattern looks OK to me; cray_pointers_2.f90 crashes badly, gfortran.dg/default_format_1.f90 (9 failures) also crashes, and a handful other programs also segfault. By the way, RTEMS (Real-Time Executive for Multiprocessor Systems) is a real-time operating system for embedded systems, which has been used, e.g., for Space missions [e.g. for the Electra software radio of Mars Reconnaissance Orbiter]. (Space projects typically means very old* hardware which is hardened and thus extremely expensive. [* long time between project start and launch.]) Its also used in the embedded system of a car manufacturer etc. Not surprising for embedded/real-time systems, the available memory is small and one has additional constraints; in case of RTEMS that there is only a single process (which might have multiple threads). Wikipedia lists around 16 supported architectures [depending how one counts].