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

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].

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.