Patchwork [Fortran] PR 51073: fix for zero-sized coarray arrays

login
register
mail settings
Submitter Tobias Burnus
Date Nov. 11, 2011, 2:24 p.m.
Message ID <4EBD302D.2010804@net-b.de>
Download mbox | patch
Permalink /patch/125176/
State New
Headers show

Comments

Tobias Burnus - Nov. 11, 2011, 2:24 p.m.
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].
Steve Kargl - Nov. 11, 2011, 5:39 p.m.
On Fri, Nov 11, 2011 at 03:24:45PM +0100, Tobias Burnus wrote:
> 
> 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 ;-)

What about memory pressure?   (I'm joking ;-)

> Build and regtested on x86-64-Linux.
> OK for the trunk?

OK.

Patch

2011-11-11  Tobias Burnus  <burnus@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);