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].
2011-11-11 Tobias Burnus <bur...@net-b.de>
PR fortran/51073
* trans-decl.c (generate_coarray_sym_init): Handle zero-sized arrays.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index b90b0ab..eb74e16 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -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);
