From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Mar 14 22:50:08 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 0C8C99DB118; Wed, 14 Mar 2012 22:50:08 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mailrelay2.lrz-muenchen.de (mailrelay2.lrz-muenchen.de [129.187.254.102]) by www.open-std.org (Postfix) with ESMTP id 778EE9DB112 for ; Wed, 14 Mar 2012 22:50:05 +0100 (CET) Received: from postout1.mail.lrz.de ([10.156.6.18] [10.156.6.18]) by mailrelay2.lrz-muenchen.de with ESMTP; Wed, 14 Mar 2012 22:49:57 +0100 Received: from BADWLRZ-SWHBT1.ads.mwn.de (BADWLRZ-SWHBT1.ads.mwn.de [IPv6:2001:4ca0:0:108::125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postout1.mail.lrz.de (Postfix) with ESMTPS id 72D2CC5826; Wed, 14 Mar 2012 22:49:57 +0100 (CET) Received: from BADWLRZ-SWMBX1.ads.mwn.de ([fe80::11b4:b130:c4e2:2d0e]) by BADWLRZ-SWHBT1.ads.mwn.de ([fe80::e42f:e9f5:bde9:f99b%16]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 22:49:57 +0100 From: "Bader, Reinhold" To: WG5 CC: "Rolf Rabenseifner (rabenseifner@hlrs.de)" Subject: AW: (SC22WG5.4645) Vote on N1904 Thread-Topic: (SC22WG5.4645) Vote on N1904 Thread-Index: AQHNAgGYA5PrUj1ECE2TcH4MfcA58ZZqUU/Q Date: Wed, 14 Mar 2012 21:49:56 +0000 Message-Id: <166ED263DF83324D9A3BA67FB6772B2B47FFA34F@BADWLRZ-SWMBX1.ads.mwn.de> References: <20120312152923.857DB9DB112@www.open-std.org> <20120314164259.A5DD4356A46@www.open-std.org> In-Reply-To: <20120314164259.A5DD4356A46@www.open-std.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4ca0:0:f031::2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk [...] >=20 > Note that the proposals to simply forbid INTENT(OUT) together with > assumed-type exclude reasonable uses of INTENT(OUT) (e.g. for MPI > receive buffers), but some constraint along those lines seems the best > solution. =20 The MPI-3 draft for the new Fortran bindings contains some remarks=20 concerning INTENT(OUT) for receive buffers which - if I remember=20 correctly - can be interpreted along the following lines * don't take the Fortran semantics of the MPI spec too seriously as an impl= ementor -=20 you're allowed to specify INTENT(INOUT) here [and would be required to if you use TYPE(*) and the above restriction is implemented in the TS] * programmer, please don't rely on other things than the buffer elements=20 written by your send NOT becoming undefined Rolf may be able to shed more light on this, so am putting him on CC here. In any case, it is not the purpose of MPI-3 to enable communication of data of types described below, so while I'm not convinced that loosening of the planned INTENT(OUT) prohibition is necessary, the below would certainly not impact MPI-3. > The following is badly worded and may not be enough, but is > put forward as a possibility:=20 > "If the actual argument corresponding to an assumed-type dummy argument > is of a type with default-initialized components, or of a type that has > has components that have the ALLOCATABLE or POINTER attributes, or are > of types with default-initialized components, the assumed-type entity > shall not have the INTENT(OUT) attribute." >=20 Regards Reinhold