From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23417 invoked by alias); 7 Jul 2011 12:49:13 -0000 Received: (qmail 23397 invoked by uid 22791); 7 Jul 2011 12:49:11 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Jul 2011 12:48:56 +0000 Received: from [192.168.178.22] (port-92-204-30-62.dynamic.qsc.de [92.204.30.62]) by mx01.qsc.de (Postfix) with ESMTP id D2ADC3DEB5; Thu, 7 Jul 2011 14:48:53 +0200 (CEST) Message-ID: <4E15AB34.80105@net-b.de> Date: Thu, 07 Jul 2011 12:53:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mikael Morin CC: fortran@gcc.gnu.org, gcc patches Subject: Re: [Patch, Fortran] Add stat=/errmsg= support to _gfortran_caf_register References: <4E15458B.8050901@net-b.de> <201107071335.34176.mikael.morin@sfr.fr> In-Reply-To: <201107071335.34176.mikael.morin@sfr.fr> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00469.txt.bz2 On 07/07/2011 01:35 PM, Mikael Morin wrote: >> if (type == CAF_REGTYPE_COARRAY_STATIC) >> { > This will return the same error (memory allocation failure) as in the case > just above. Is this expected or should it have an error of its own? I think it is OK in either case. CAF_REFTYPE_COARRAY_STATIC is an automatic allocation for static coarrays, e.g. REAL, SAVE :: my_coarray(1000,1000,10)[*] is allocated at startup (via a constructor) while the other case is for allocatable coarrays of the form REAL, ALLOCATABLE :: my_alloc_coarray(:, :, :)[:] ALLOCATE (my_alloc_coarray(1000,1000,10)[*]) I admit that it is might be not obvious to the user that there is an explicit allocate in the first case. However, one allocates memory in either case and, thus, one could leave the message as is. In particular, I would assume that on most systems, the size of static coarrays is small enough that the message does not trigger. However, if you think that the message could be clearer, I could also change it. >> + msg = "Failed to allocate coarray - stopped images"; > > Also I'm wondering whether it would be pertinent to share the error handling > between single.c (one error) and mpi.c (2 or 3 errors) as the codes are very > close (with an interface such as handle_error (int *stat, char *errmsg, int > errmsg_len, char *actual_error)). The question is where to handle it; in principle, single.c and mpi.c are completely separate files - and both might be compiled by the user/system administrator, contrary to the rest of GCC. Well, single.c is actually automatically compiled as static library and installed as libcaf_single.a. The MPI version is never compiled automatically. Thus, anyone who wants to use gfortran with coarrays (based on mpi.c), has to do: a) Fetch libcaf.h and mpi.c b) Compile mpi.c, e.g., using mpicc -g -O2 -c mpi.c c) Link the such generated mpi.o (or libcaf_mpi.a) to the Fortran program. As the user/sysadmin as to do the compiliation himself, I would like to make it as easy as possible. The current idea is to have just a single C file plus a header file and no further dependency. Other communication backends could be added by simply creating a new file and implementing the library calls. Thus, I do not see how one could best share single.c and mpi.c error messages. But if you have a good idea, I am open to change the current implementation. (See also http://gcc.gnu.org/wiki/CoarrayLib ) >> Build and regtested on x86-64-linux. >> OK for the trunk? > The above is nitpicking, and I leave the final decision to you and Daniel, so > the patch is basically OK with the two indentation nits fixed. I have now committed the patch with only the nits fixed (Rev.175966). But given that the coarray support - especially with regards to the library - is still in a flux, we can still change everything, including the ABI of the library and the file organization. I am sure that not all design decisions are optimal. Thanks for the review! Tobias