From owner-sc22wg5@open-std.org Wed Nov 12 01:13:29 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id DF1FAC178D9; Wed, 12 Nov 2008 01:13:29 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by www2.open-std.org (Postfix) with ESMTP id 9D316C178D6 for ; Wed, 12 Nov 2008 01:13:27 +0100 (CET) Received: from mprox1.jpl.nasa.gov (mprox1.jpl.nasa.gov [137.78.160.140]) by mail.jpl.nasa.gov (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id mAC0DN92017624 for ; Wed, 12 Nov 2008 00:13:23 GMT Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) (authenticated bits=0) by mprox1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id mAC0DLVd007235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 11 Nov 2008 16:13:22 -0800 Subject: Re: (j3.2006) (SC22WG5.3663) [ukfortran] N1755: Request for new features from MPI Forum From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov Cc: WG5 In-Reply-To: <20081111234923.517C5C178D6@www2.open-std.org> References: <49137AD3.1070402@lrz.de> <20081111214622.271B9C178D6@www2.open-std.org> <20081111223447.BD40BC178D9@www2.open-std.org> <20081111224927.8201CC178D9@www2.open-std.org> <20081111234923.517C5C178D6@www2.open-std.org> Content-Type: text/plain Organization: Yes Date: Tue, 11 Nov 2008 16:13:21 -0800 Message-Id: <1226448801.26045.716.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.2) Content-Transfer-Encoding: 7bit X-Source-IP: math.jpl.nasa.gov [137.79.7.57] X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Tue, 2008-11-11 at 15:51 -0800, Bill Long wrote: > > 2. "C559 An entity with the VOLATILE attribute shall be a variable that is not > > an INTENT (IN) dummy argument." > > Please explain this one to me. > > > > INTENT(IN) implies that the dummy argument does not change its value > (for the non-pointer case) inside the subprogram. It allows the > compiler to snap a copy of the variable in a register and keep it there > throughout execution of the subprogram, for example. Pretty much > completely incompatible with the implications of volatile. Mo, INTENT(IN) says that such a dummy argument shall not appear in a variable definition context. Without VOLATILE that's (almost) the same thing, but if the actual argument really is volatile, wouldn't INTENT(IN) + VOLATILE say "don't take a copy?" Given that INTENT(IN) on its own is incompatible with VOLATILE, isn't that a reason to specify VOLATILE when it's needed, instead of not being able to specify it? Prohibiting VOLATILE + VALUE is even more nonsensical, since the procedure is allowed to change VALUE dummy arguments. Why can't one change while you're not looking? VOLATILE + VALUE means "take a copy, and then the copy might change while you're not looking." Do we prohibit these? integer, intent(in), target :: X integer, pointer, volatile :: Y Y => X call foobar ( Y ) ! which keeps Y and makes volatile changes ! to its target integer, value, target :: X integer, pointer, volatile :: Y Y => X call foobar ( Y ) ! which keeps Y and makes volatile changes ! to its target I couldn't find a constraint in 7.2.2 "If the has the VOLATILE attribute the target shall not have the VALUE or INTENT(IN) attributes." If we don't prohibit them, why bother with the cases that don't involve pointers? I also didn't find constraints in 5.3.18-19 against TARGET + VALUE or VOLATILE. Indeed, I didn't find a constraint against TARGET + INTENT(IN), so I hope INTENT(IN) doesn't mean what Bill says, at least in this case. -- Van Snyder | What fraction of Americans believe Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, the President, or anybody else.