<div dir="ltr">Jeff,<div><br></div><div>I don't think that anyone is making an argument that is specific to 32b architectures. The concern is that the MPI standard currently requires:</div><div><br></div><div>(1) a two's complement architecture where overflow/underflow of signed arithmetic on an unsigned quantity always results in the right unsigned value</div>
<div>- OR -</div><div>(2) an MPI_Aint type that is 2x the size of an address to ensure that overflow/underflow never occurs (because MPI_BOTTOM is an arbitrary address in Fortran)</div><div><br></div><div>Given that every system I know of falls into category (1) and there is a solution (2) for all other systems, I am not trying to recall why we felt that this problem needs to be solved through new arithmetic routines. I believe there was a concern that 128-bit integers are not standard and not well supported by most languages/architectures, so (2) may not be a workable solution. Maybe Dave G [added to cc] remembers our rationale?</div>
<div><br></div><div> ~Jim.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 20, 2013 at 8:35 AM, Jeff Hammond <span dir="ltr"><<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">32b Blue Gene is dead. We are turning ours off in 2 weeks.<br>
<br>
The only 32b arguments should be relevant to ARM and other cell phone parts that may run MPI some day.<br>
<br>
Jeff<br>
<br>
Sent from my iPhone<br>
<div class="HOEnZb"><div class="h5"><br>
> On Dec 20, 2013, at 5:04 AM, Rolf Rabenseifner <<a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a>> wrote:<br>
><br>
> Hi Jim,<br>
><br>
>> I don't think that the proposal is in conflict with sections 2.5.6 or<br>
>> 4.1.5. These sections are talking about addresses and not<br>
>> specifically about how one can use the MPI_Aint type. We mean to<br>
>> address only the latter item -- correct usage of the MPI address<br>
>> integer type.<br>
><br>
> I also do not see a conflict.<br>
> But I see that the new concept must be explained within these sections.<br>
> This is about consistency of the whole MPI document.<br>
><br>
>> In terms of where to put the proposed text in the chapter, I suggest<br>
>> we make that a separate discussion, once the technical issues have<br>
>> been resolved.<br>
><br>
> As you mentioned below,<br>
> technically there are two solutions:<br>
> A. require that disp=addr2-addr1 and addr2=addr1+disp can be<br>
> calculated with the intrinsic arithmetic operations - and +.<br>
> This would require:<br>
> 128 bit MPI_Aint on a system that<br>
> - uses full 64 bit absolute addresses, AND<br>
> - does not have one-s complement arithmetic AND<br>
> - MPI_BOTTOM is not defined in the middle<br>
> B. require that disp=addr2-addr1 and addr2=addr1+disp<br>
> is calculated with your two new functions to guarantee<br>
> that always 64 bits signed MPI_Aint are enough<br>
> to store any 64 bit unsigned absolute addresses.<br>
><br>
> If we decide A, then only an advice to implementers would be fine.<br>
> If we decide B, then several "corrections" are needed.<br>
><br>
>> I do have a concern, in particular, about section 4.1.12, "Correct<br>
>> use of Addresses", which seems to suggest that one should be able to<br>
>> do arithmetic directly on absolute addresses stored in address<br>
>> integers. The only way that this could be supported on some<br>
>> platforms (e.g. one's complement integers) is to make the MPI_Aint<br>
>> an integer that is larger than an address, so that<br>
>> overflow/underflow cannot occur. Because of Fortran's dynamic<br>
>> MPI_BOTTOM, address integers on such a platform would have to be<br>
>> 128-bits to ensure that there can be no overflow.<br>
>><br>
>> What's your take on that section?<br>
><br>
> The notations MPI-3.0 page 115 lines 42 and 47 v+i and u-v<br>
> need not to be interpreted as C and Fortran + and -.<br>
><br>
> One could say that there is a lack of not having defined<br>
> these operations.<br>
><br>
> I principle, you are right when you expect (as all MPI-readers so far)<br>
> that + and - on these lines are C and Fortran + and -,<br>
> and therefore, solution A is required.<br>
> Note that solution A is not the worst because our systems have IEEE<br>
> data representation which has one's complements and therefore no Need<br>
> for doubling the size of MPI_Aint, especially on the pure 32-bit Blue-Gene<br>
> Systems.<br>
><br>
> If one wants to go with B (and this is a free Forum decision)<br>
> then one should add text to<br>
>> MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and<br>
>> MPI-3.0 Sect. 4.1.5, page 102 lines 28-35<br>
> and also to<br>
> - MPI 3.0 Sect. 4.1.12, page 115 line 48, e.g.,<br>
> "Note that v+i and u-v need to be calculated<br>
> with MPI_AINT_ADD and MPI_AINT_DIFF."<br>
> And the two new routines after page 103 line 46.<br>
><br>
> My mails only try to help that proposal B is fully complete<br>
> and consistent.<br>
> They are not about whether I would like to have A or B.<br>
> Because A continues to stay a work-around for B,<br>
> I would be happy with B.<br>
><br>
> Best regards<br>
> Rolf<br>
><br>
><br>
> ----- Original Message -----<br>
>> From: "Jim Dinan" <<a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a>><br>
>> To: "Rolf Rabenseifner" <<a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a>><br>
>> Cc: "MPI-WG Fortran working group" <<a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a>>, "longb" <<a href="mailto:longb@cray.com">longb@cray.com</a>><br>
>> Sent: Thursday, December 19, 2013 9:55:42 PM<br>
>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question<br>
>><br>
>><br>
>> Hi Rolf,<br>
>><br>
>><br>
>> I don't think that the proposal is in conflict with sections 2.5.6 or<br>
>> 4.1.5. These sections are talking about addresses and not<br>
>> specifically about how one can use the MPI_Aint type. We mean to<br>
>> address only the latter item -- correct usage of the MPI address<br>
>> integer type.<br>
>><br>
>><br>
>> In terms of where to put the proposed text in the chapter, I suggest<br>
>> we make that a separate discussion, once the technical issues have<br>
>> been resolved.<br>
>><br>
>><br>
>> I do have a concern, in particular, about section 4.1.12, "Correct<br>
>> use of Addresses", which seems to suggest that one should be able to<br>
>> do arithmetic directly on absolute addresses stored in address<br>
>> integers. The only way that this could be supported on some<br>
>> platforms (e.g. one's complement integers) is to make the MPI_Aint<br>
>> an integer that is larger than an address, so that<br>
>> overflow/underflow cannot occur. Because of Fortran's dynamic<br>
>> MPI_BOTTOM, address integers on such a platform would have to be<br>
>> 128-bits to ensure that there can be no overflow.<br>
>><br>
>><br>
>> What's your take on that section?<br>
>><br>
>><br>
>> ~Jim.<br>
>><br>
>><br>
>><br>
>> On Fri, Dec 13, 2013 at 9:11 AM, Rolf Rabenseifner <<br>
>> <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> > wrote:<br>
>><br>
>><br>
>> Jim,<br>
>><br>
>><br>
>>> Could you provide a list of the specific changes that you feel are<br>
>>> needed on these tickets?<br>
>><br>
>> I expected that you are doining this.<br>
>> I only want to mention the locations.<br>
>><br>
>> Your new model differentiates beween<br>
>> - absolute addresses generated from locations with MPI_GET_ADDRESS<br>
>> - relative displacements as differences of two absolute addresses<br>
>> and the needed arithmetic<br>
>> - relative displacements with normal + - * arithmetic<br>
>> - absolute addresses and displacments with<br>
>> MPI_AINT_ADD and MPI_AINT_DIFF arithmetic<br>
>><br>
>> Therefore:<br>
>> MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and<br>
>> MPI-3.0 Sect. 4.1.5, page 102 lines 28-35<br>
>> should reflect this differentiation.<br>
>><br>
>> The proposed rationale in #349 may go at the end of page 102 lines<br>
>> 28-35.<br>
>> After MPI-3.0 Sect. 4.1.5, page 103 line 46, you should add<br>
>> MPI_AINT_ADD and MPI_AINT_DIFF.<br>
>><br>
>><br>
>> Best regards<br>
>> Rolf<br>
>><br>
>><br>
>><br>
>> ----- Original Message -----<br>
>>> From: "Jim Dinan" < <a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a> ><br>
>>> To: "Rolf Rabenseifner" < <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> ><br>
>>> Cc: "MPI-WG Fortran working group" <<br>
>>> <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a> >, "longb" < <a href="mailto:longb@cray.com">longb@cray.com</a> ><br>
>><br>
>><br>
>>> Sent: Friday, December 13, 2013 1:35:13 PM<br>
>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question<br>
>>><br>
>>><br>
>>> Rolf,<br>
>>><br>
>>><br>
>>> Could you provide a list of the specific changes that you feel are<br>
>>> needed on these tickets? For reference, and to bring in feedback<br>
>>> from others on the cc, we are discussing:<br>
>>><br>
>>><br>
>>> MPI_Aint_add --<br>
>>> <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349</a><br>
>>> Linked list example updates --<br>
>>> <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402</a><br>
>>> MPI_Aint_diff --<br>
>>> <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404</a><br>
>>><br>
>>><br>
>>> Let's solve the technical issues first to see where things stand,<br>
>>> and<br>
>>> then come back to the issue of how to handle voting on these<br>
>>> changes.<br>
>>><br>
>>><br>
>>> Thank you for helping to improve these tickets!<br>
>>><br>
>>><br>
>>> Best,<br>
>>> ~Jim.<br>
>>><br>
>>><br>
>>><br>
>>> On Thu, Dec 12, 2013 at 12:34 PM, Rolf Rabenseifner <<br>
>>> <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> > wrote:<br>
>>><br>
>>><br>
>>> Dear Jim,<br>
>>><br>
>>> I would like to disagree.<br>
>>> Looking at #349, I see wording like "base address" etc.<br>
>>> whereas MPI-3.0 p102.29 uses "absolute address".<br>
>>><br>
>>> And, the ticket does not show the location of the new text,<br>
>>> nor all the needed background info.<br>
>>><br>
>>> MPI is a standard document and the proposed change<br>
>>> (absolute addresses can no longer be used in<br>
>>> normal arithmetic) should be well prepared.<br>
>>><br>
>>> The current text is not ready.<br>
>>><br>
>>> You start to differentiate between "absolute addresses"<br>
>>> and "relative displacements" and their use of MPI_Aint.<br>
>>><br>
>>> Please have a look at 2.5.6 on page 16.<br>
>>> This section should be clarified.<br>
>>><br>
>>> Please try to produce one proposal that is complete<br>
>>> and fits to the standard.<br>
>>> Voting in small pieces (several tickets) is not the best.<br>
>>><br>
>>><br>
>>> Best regards<br>
>>> Rolf<br>
>>><br>
>>> ----- Original Message -----<br>
>>>> From: "Jim Dinan" < <a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a> ><br>
>>>> To: "Rolf Rabenseifner" < <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> ><br>
>>>> Cc: "MPI-WG Fortran working group" <<br>
>>>> <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a> >, "longb" < <a href="mailto:longb@cray.com">longb@cray.com</a> >,<br>
>>>> "Jim Dinan"<br>
>>>> < <a href="mailto:dinan@mcs.anl.gov">dinan@mcs.anl.gov</a> ><br>
>>><br>
>>><br>
>>>> Sent: Thursday, December 12, 2013 5:51:30 PM<br>
>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question<br>
>>>><br>
>>>><br>
>>>> Hi Rolf,<br>
>>>><br>
>>>><br>
>>>> Thanks for the corrections -- I apologize, what I had sent was a<br>
>>>> very<br>
>>>> rough draft of the proposal. I applied your changes to the<br>
>>>> proposal, cleaned some things up, and added the datatypes<br>
>>>> examples<br>
>>>> corrections. Could you take another look when you get a chance?<br>
>>>><br>
>>>><br>
>>>> In terms of proposal logistics, I would like to let MPI_Aint add<br>
>>>> and<br>
>>>> diff tickets progress independently. I agree that they need to<br>
>>>> be<br>
>>>> together, and I think we can rely on the chapter committee to<br>
>>>> handle<br>
>>>> that if add/diff end up split between two versions of the<br>
>>>> standard.<br>
>>>> MPI_Aint_diff should be ready for a reading at the next meeting<br>
>>>> and<br>
>>>> MPI_Aint_add will be ready for a first vote. Given the<br>
>>>> discussion<br>
>>>> about MPI 3.x/4.0 timeline yesterday, I think the risk of these<br>
>>>> not<br>
>>>> being in the same release of the spec is very low. Since the<br>
>>>> Forum<br>
>>>> has already done all of the work required to move MPI_Aint_add to<br>
>>>> a<br>
>>>> vote, I would prefer not to rewind this process by merging it<br>
>>>> with<br>
>>>> the diff ticket.<br>
>>>><br>
>>>><br>
>>>> ~Jim.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Thu, Dec 12, 2013 at 9:14 AM, Rolf Rabenseifner <<br>
>>>> <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> > wrote:<br>
>>>><br>
>>>><br>
>>>> Jim and all,<br>
>>>><br>
>>>> MPI_Get_address((char *) addr1 - (char *) addr2, &result)<br>
>>>><br>
>>>> This is really wrong, because (char *) addr1 - (char *) addr2<br>
>>>> is not an address and cannot be used as input to MPI_Get_address.<br>
>>>><br>
>>>> (char *) addr1 - (char *) addr2 is a displacement.<br>
>>>><br>
>>>> Both tickets 349 and 404 need to be together, because they<br>
>>>> are based on a clear distinguishing between<br>
>>>> - Location in memory (input of MPI_GET_ADDRESS), e.g. x, y<br>
>>>> - absolute addresses (output of MPI_GET_ADDRESS), e.g., addr_x,<br>
>>>> addr_y<br>
>>>> - relative displacements (diff of two absolute addresses), e.g.<br>
>>>> dist_xy<br>
>>>><br>
>>>> Your new statement is that calculations like<br>
>>>> dist_xy = addr_y - addr_x<br>
>>>> addr_y = addr_x + dist_xy<br>
>>>> need to be done by subroutine calls or functions,<br>
>>>> because absolute addresses are stored in MPI_Aint variables<br>
>>>> through some (unknown/strange) mapping,<br>
>>>> wheras relative displacements are normal unsigned integers<br>
>>>> that can be used for normal arithmetic.<br>
>>>><br>
>>>> The one ticket must show this clearly and must be integrated into<br>
>>>> section 4.1.5<br>
>>>><br>
>>>><br>
>>>> Best regards<br>
>>>> Rolf<br>
>>>><br>
>>>><br>
>>>> ----- Original Message -----<br>
>>>><br>
>>>><br>
>>>>> From: "Jim Dinan" < <a href="mailto:james.dinan@gmail.com">james.dinan@gmail.com</a> ><br>
>>>>> To: "Rolf Rabenseifner" < <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> ><br>
>>>>> Cc: "MPI-WG Fortran working group" <<br>
>>>>> <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a> >, "longb" < <a href="mailto:longb@cray.com">longb@cray.com</a><br>
>>>>>> ,<br>
>>>>> "Jim Dinan"<br>
>>>>> < <a href="mailto:dinan@mcs.anl.gov">dinan@mcs.anl.gov</a> ><br>
>>>>> Sent: Thursday, December 12, 2013 3:20:41 PM<br>
>>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question<br>
>>>>><br>
>>>>><br>
>>>>> Hi Rolf,<br>
>>>>><br>
>>>>><br>
>>>>> Thank you very much for the feedback! Sorry if I forgot to<br>
>>>>> respond;<br>
>>>>> the comments definitely were not ignored. We discussed the<br>
>>>>> Aint<br>
>>>>> difference calculation in the working group and decided to<br>
>>>>> create<br>
>>>>> an<br>
>>>>> additional ticket for MPI_Aint_disp. We did not see a clean<br>
>>>>> way<br>
>>>>> to<br>
>>>>> handle this in MPI_Aint_add, because both arguments need to be<br>
>>>>> handled as unsigned in the arithmetic.<br>
>>>>><br>
>>>>><br>
>>>>> <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> I have a list of fixes the to the datatypes examples that I'll<br>
>>>>> post<br>
>>>>> to the ticket soon.<br>
>>>>><br>
>>>>><br>
>>>>> Jeff Squyres is also helping us move the MPI_Aint arithmetic<br>
>>>>> routines<br>
>>>>> to functions in the Fortran bindings. Should be done today.<br>
>>>>><br>
>>>>><br>
>>>>> Were there any other concerns that we missed?<br>
>>>>><br>
>>>>><br>
>>>>> Thanks,<br>
>>>>> ~Jim.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Thu, Dec 12, 2013 at 1:42 AM, Rolf Rabenseifner <<br>
>>>>> <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a> > wrote:<br>
>>>>><br>
>>>>><br>
>>>>> Jeff and Bill,<br>
>>>>><br>
>>>>> <<br>
>>>>> <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22" target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22</a><br>
>>>>> was ignored.<br>
>>>>> The answer seems to be yes and the clear implication is that<br>
>>>>> we need also a routine to calculate disp := addr2-addr1<br>
>>>>><br>
>>>>> About the Fortran Interfaces:<br>
>>>>> We should keep the old style without INTENT, because for the<br>
>>>>> old-style<br>
>>>>> the implementor has the freedom to add INTENT as he/she wants<br>
>>>>> and it is still compliant with the outcome of the definition.<br>
>>>>><br>
>>>>> I do not see, why we have a function in C and a subroutine<br>
>>>>> in Fortran.<br>
>>>>> Like MPI_Wtime, in all three languages (C, new and old<br>
>>>>> Fortran),<br>
>>>>> we should do the same.<br>
>>>>><br>
>>>>> Best regards<br>
>>>>> Rolf<br>
>>>>><br>
>>>>> ----- Original Message -----<br>
>>>>>> From: "Jeff Squyres (jsquyres)" < <a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a> ><br>
>>>>>> To: "< <a href="mailto:longb@cray.com">longb@cray.com</a> >" < <a href="mailto:longb@cray.com">longb@cray.com</a> >, "MPI-WG Fortran<br>
>>>>>> working group" < <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a> ><br>
>>>>>> Sent: Thursday, December 12, 2013 12:17:40 AM<br>
>>>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran<br>
>>>>>> question<br>
>>>>>><br>
>>>>>> Sounds good to me.<br>
>>>>>><br>
>>>>>> Rolf -- is there any MPI reason we would not want to do this?<br>
>>>>>><br>
>>>>>><br>
>>>>>> On Dec 11, 2013, at 4:41 PM, Bill Long < <a href="mailto:longb@cray.com">longb@cray.com</a> ><br>
>>>>>> wrote:<br>
>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>>> On 12/11/13 11:27 AM, Jeff Squyres (jsquyres) wrote:<br>
>>>>>>>> This ticket got a formal reading today at the Forum:<br>
>>>>>>>><br>
>>>>>>>> <a href="http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349" target="_blank">http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349</a><br>
>>>>>>>> (as of this writing, there's still a BIND(C) in there,<br>
>>>>>>>> but<br>
>>>>>>>> it<br>
>>>>>>>> will be removed shortly)<br>
>>>>>>>><br>
>>>>>>>> The function is basically intended to perform a<br>
>>>>>>>> mathematical<br>
>>>>>>>> operation. As such, I think that the 2 Fortran bindings<br>
>>>>>>>> should<br>
>>>>>>>> be FUNCTIONs, not SUBROUTINEs (a la MPI_WTICK/MPI_WTIME).<br>
>>>>>>>><br>
>>>>>>>> Do you agree? If so, the ticket author (Jim Dinan) is<br>
>>>>>>>> amenable<br>
>>>>>>>> to<br>
>>>>>>>> changing the Fortran bindings to the following (and I'm<br>
>>>>>>>> assuming<br>
>>>>>>>> I have the syntax below correct, but feel free to correct<br>
>>>>>>>> me<br>
>>>>>>>> if<br>
>>>>>>>> they're wrong):<br>
>>>>>>><br>
>>>>>>> Certainly it makes more sense for these to be functions in<br>
>>>>>>> Fortran.<br>
>>>>>>> Particularly if the programmer prefers supply an interface<br>
>>>>>>> and<br>
>>>>>>> call the C form directly. If the C and Fortran versions<br>
>>>>>>> are<br>
>>>>>>> both<br>
>>>>>>> functions, there is no change in the source code where the<br>
>>>>>>> function is used.<br>
>>>>>>><br>
>>>>>>>> -----<br>
>>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_Aint_add(base, disp)<br>
>>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) :: base,<br>
>>>>>>>> disp<br>
>>>>>>>><br>
>>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_AINT_ADD(BASE, DISP)<br>
>>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) BASE, DISP<br>
>>>>>>><br>
>>>>>>> It is certainly an oddity that the spec has two forms like<br>
>>>>>>> this.<br>
>>>>>>> Any version of the Fortran standard that supports KIND= in<br>
>>>>>>> INTEGER also supports lower case names and INTENT()<br>
>>>>>>> attributes.<br>
>>>>>>> Maybe there could be some clean up of this in a future<br>
>>>>>>> revision.<br>
>>>>>>><br>
>>>>>>> Cheers,<br>
>>>>>>> Bill<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>>> -----<br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> Bill Long<br>
>>>>>>> <a href="mailto:longb@cray.com">longb@cray.com</a><br>
>>>>>>> Fortran Technical Support & voice:<br>
>>>>>>> <a href="tel:651-605-9024" value="+16516059024">651-605-9024</a><br>
>>>>>>> Bioinformatics Software Development fax:<br>
>>>>>>> <a href="tel:651-605-9142" value="+16516059142">651-605-9142</a><br>
>>>>>>> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul,<br>
>>>>>>> MN<br>
>>>>>>> 55101<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>>> mpiwg-fortran mailing list<br>
>>>>>>> <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
>>>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Jeff Squyres<br>
>>>>>> <a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a><br>
>>>>>> For corporate legal information go to:<br>
>>>>>> <a href="http://www.cisco.com/web/about/doing_business/legal/cri/" target="_blank">http://www.cisco.com/web/about/doing_business/legal/cri/</a><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> mpiwg-fortran mailing list<br>
>>>>>> <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
>>>>>> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
>>>>><br>
>>>>> --<br>
>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email<br>
>>>>> <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
>>>>> High Performance Computing Center (HLRS) . phone<br>
>>>>> <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
>>>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 /<br>
>>>>> 685-65832<br>
>>>>> Head of Dpmt Parallel Computing . . .<br>
>>>>> <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
>>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room<br>
>>>>> 1.307)<br>
>>>><br>
>>>> --<br>
>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email<br>
>>>> <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
>>>> High Performance Computing Center (HLRS) . phone<br>
>>>> <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
>>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 /<br>
>>>> 685-65832<br>
>>>> Head of Dpmt Parallel Computing . . .<br>
>>>> <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room<br>
>>>> 1.307)<br>
>>><br>
>>> --<br>
>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email<br>
>>> <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
>>> High Performance Computing Center (HLRS) . phone<br>
>>> <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 /<br>
>>> 685-65832<br>
>>> Head of Dpmt Parallel Computing . . .<br>
>>> <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room<br>
>>> 1.307)<br>
>><br>
>> --<br>
>> Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
>> High Performance Computing Center (HLRS) . phone <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
>> University of Stuttgart . . . . . . . . .. fax <a href="tel:%2B%2B49%280%29711%20%2F%20685-65832" value="+4971168565832">++49(0)711 / 685-65832</a><br>
>> Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)<br>
><br>
> --<br>
> Dr. Rolf Rabenseifner . . . . . . . . . .. email <a href="mailto:rabenseifner@hlrs.de">rabenseifner@hlrs.de</a><br>
> High Performance Computing Center (HLRS) . phone <a href="tel:%2B%2B49%280%29711%2F685-65530" value="+4971168565530">++49(0)711/685-65530</a><br>
> University of Stuttgart . . . . . . . . .. fax <a href="tel:%2B%2B49%280%29711%20%2F%20685-65832" value="+4971168565832">++49(0)711 / 685-65832</a><br>
> Head of Dpmt Parallel Computing . . . <a href="http://www.hlrs.de/people/rabenseifner" target="_blank">www.hlrs.de/people/rabenseifner</a><br>
> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)<br>
> _______________________________________________<br>
> mpiwg-fortran mailing list<br>
> <a href="mailto:mpiwg-fortran@lists.mpi-forum.org">mpiwg-fortran@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran</a><br>
</div></div></blockquote></div><br></div>