(j3.2006) Some J3 papers and unfinished business

[Aleksandar Donev]

Hi,

I am trying to upload the attached papers via the new script...in any case, I 
think it is useful to share with everyone so we don't duplicate eachother's 
work. A few more on macros coming soon...Bill and John are as usual in charge 
of the CAF issues...I won't make it to 179 but have worked with them on the 
responses. If someone can share their notes from the meeting with me after it 
is done please send them to me (I'll ignore any personal content :-).

Now some things I am running out of time to do but I know should be done:

1. Is anyone going to answer Dick's questions from 06-342 (John?) please?

2. I have the following TODO in my list, but no time to do it. Someone (Van?) 
please note it and please do it at the meeting:

-------------
06-344r1:
Q. [55:4] Is "ultimate/direct component of a type" well-defined? We have
   subcomponents of an object, and ultimate/direct components of an object. 
   How about of a type? This is important because we have used this phrase
   heavily, especially for co-arrays (see for example C616 at [117:13-14]).
A. No, it is not explicitly defined; you should not be using such a term.
   In particular, C616 is faulty.
EDIT. [117:13-14] "be of a type that has" -> "have".
COMMENT. Please point out any other places for similar repair.
-------------

3. 377r1: This question is not yet answered. I find it discomforting that no 
one knows the answer. Someone added the restriction to the standard!?!

-------------
[314:12+] I find Note 12.27 confusing and misleading. Why is it talking
about the actual argument being defined asynchronously when it is the
dummy that has the ASYNCHRONOUS attribute? Why do we even prohibit copy
in/out when the dummy has asynchronous? Can't the asynchronicity be
confined within the procedure itself. It is really the actual being
modified while the procedure is executing that is the problem.

real :: y(10,10)
call read_file(y(1,:)) ! What is wrong with copy in/out???

subroutine read_file(x)
  real, asynchronous :: x(10) ! Will be used in async IO
end subroutine
-------------

Thanks,
Aleks

-- 
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ LLNL
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev
-------------- next part --------------
To:                                                              07-xxx
From: Aleksandar Donev
Subject: Definition of "compile time contiguous"

References: 06-311r1, 07-007, UTI 101

A straw vote was taken as proposed in 06-311 and it was recommended
that pointer rank remapping for contiguous targets only be allowed
when the target can be determined to be contiguous at compile-time
(see UTI 101). A reasonable definition of this was already crafted
at an earlier meeting and can be found at [319:7-16]. All that is
needed is to name it and move it some place else. I propose the phrase
"always-contiguous" and will use that as a placeholder. We also need
to change rank-remapping restrictions.

I also propose that we use this constraint in certain places where we
currently have restrictions to ensure there is no copy in/out of dummy
arguments. For example, restrictions on co-array passing, VOLATILE
and ASYNCHRONOUS. Specifically, if the actual is always-contiguous,
copy in/out does not need to be used. We already did this for
co-arrays...this paper adds the rest of the edits.

In this paper I do not propose to change anything about TARGETs and
pointer-association accross argument passing as this is complex and
should first be subjected to a technical discussion.

QUESTION:
I do not remember whether the straw vote discussion also included
regular (non rank-remapping) pointer assignment. If it did, we also
need to replace "contiguous" with "always-contiguous" at [165:9]. How
about arguments to C_LOC (see [471:10])? I recommend that we do not
require always-contiguous variables in those cases since in some
cases the definition of always contiguous might be too restrictive.

Edits:
----------

[165:10] Replace "<data-target> shall be contiguous (5.3.6)" with:
"<data-target> shall be always contiguous (5.3.6)"

[90:22-] Before section 5.3.7, add a new paragraph:
"An object is <<always-contiguous>> if it satisfies the following
conditions."
Then copy [319:7-16+] here including Note 12.30. Add a final sentence
to the Note:
"An always-contiguous object is a contiguous object."

[316:30] In C1235 replace
"If an actual argument is an array section or an assumed-shape
array," with
"If an actual argument is not a pointer array and is not
always-contiguous,"

[317:1] In C1236 replace:
"If an actual argument is a pointer array," with
"If an actual argument is a pointer array that does not have the
CONTIGUOUS attribute,"

[319:6] Replace the end of the paragraph "shall satisfy the following
conditions." with:
"shall be always-contiguous."

[320:2] Replace "compile-time contiguous" with "always-contiguous"

# EOF
-------------- next part --------------
To: 07-xxx
From: Aleksandar Donev
Subject: Binding labels for internal interoperable procedures
References: 06-352r3, 07-007, UTI 103

UTI 103 (page 330) gives two choices. I believe that the discussion
at meeting 178 during the discussion of 06-352r3 we agreed to do
choice 2. Since the editor implemented choice 1, this paper proposes
reverting back to choice 2. A straw vote is recommended.

The editor says:

"2. manual prohibition of binding name:
-remove the 15.5.2 text inserted by 06-352r3,
-reinstate C1240 from 06-352r3, and
-undo my change to C1239."
The edits for this are given below.

Edits
---------

[481:7] Delete ", an internal procedure,"

[330:14] Delete "an internal procedure, or of"

[330:15+] Add a new constraint:
C1248a (R1229) If a <proc-language-binding-spec> is specified for an
internal procedure, the NAME= specifier shall appear and it shall
specify that the procedure has no binding label (15.4.1).

# EOF