Subject: an implementor's request for clarification

From: David Loveman <[email-masked]>
Date: Tue, 19 May 92 11:23:43 PDT

An Implementor's concerns:

  Q1:  The DECOMPOSITION directive must precede a DISTRIBUTION directive
       and ALIGN directives when the arrays and decompositions
       relate to each other?

	 Answer:		True		False	      DontKnow

	 Note:  Please say True.

	 Example (i)

	 !HPF$  DECOMPOSITION   ...  decomposition-name  ...		
	 !HPF$  DISTRIBUTE	...  decomposition-name  ...
	 !HPF$  ALIGN		...  array-name ... decomposition-name ...

  Q2:  Must all f90 declarations for  array-name  be uttered before
       an ALIGN directive referring to array-name is seen?

	 Answer:		True		False	      DontKnow

	 Notes: One can write in f90 in any order, e.g.:

	       REAL	 x
	       DIMENSION x(100)

	 Furthermore, COMMON, INTENT, PUBLIC, PRIVATE, ALLOCATABLE, etc.,
	 can be written in random order provided that combination of
	 attributes can semantically merge.  F90 does have the composite
	 type statement, but F90 allows for specifying the attributes
	 on separate statements, too.

	 We don't want unneeded implementation complexities because of the
	 directives, if possible.

	 Example (ii)

	 !HPF$  ALIGN	...	x	...
	        REAL x; DIMENSION x(100)

	        REAL x; DIMENSION x(100)	! this is the only combo
	 !HPF$  ALIGN	...	x	...	!  I'd like to be okay

	        DIMENSION 	x(100)
	 !HPF$  ALIGN	...	x	...
	        REAL x

				True		False		DontKnow

  Q3:   An association directive with an  entity-list, e.g.,

	 !HPF$ SEQUENCE_ASSOCIATION  s

	must be processed when seen and there can be no f90 declaration
	statement or ALIGN directive referencing  s  appearing ahead it.

	Answer:		True		False		DontKnow

  Q4:   An association directive with no  entity-list, e.g.,

	 !HPF$ SEQUENCE_ASSOCIATION

	must appear before any declarations are made?

	Answer:		True		False		DontKnow

		SUBROUTINE T(X,Y)
          !HPF$ SEQUENCE_ASSOCIATION  
		REAL x(100), Y(100)

	or should it be

          !HPF$ SEQUENCE_ASSOCIATION  		! This in my opinion is
		SUBROUTINE T(X,Y)		!  the correct form
		REAL x(100), Y(100)		
	
	but never

		SUBROUTINE T(X,Y)
		REAL x(100), Y(100)
          !HPF$ SEQUENCE_ASSOCIATION  

  Q5:   A decomposition-name  or a  processor-name, i.e., an abstract name
        from directives, must not be the name of any other entity in a
        scoping unit (other than the name sharing of COMMON block names
        that already is in Fortran).

        Note:  Please, please, say true on this one.

        Answer:		True		False		DontKnow

  Q6:  An  align-subscript-name  is described as a 'distinct, simple variable
       name'.  Is this the same as the statement:  'an align-subscript-name
       has the scope of the directive only'?

        Answer:		True		False		DontKnow

  Q7:  The type of an  align-subscript-name  is default integer, and the
       appearance of an  align-subscript-name  on a type statement has no
       effect.

        Answer:		True		False		DontKnow

	Note: align-subscript-names  are akin to  implied-do-variables on
	  DATA statements and statement function dummy arguments in that the
	  scope of these guys is that statement only, but appearance of the
	  name on a type statement (assuming it appears ahead)
	  is permitted and honored.  Otherwise implicit typing rules are in
	  effect.

  S1:   If Q6 is true, then the statement

	   align-spec-expr  is  specification-expr      -- for ALIGN
	   align-spec-expr  is  int-expr		-- for REALIGN

	is wrong since an align-spec-expr will contain  primaries  that are
	align-subscript-names.  Such critters are not allowed either in a
	specification-expr  or an  int-expr   as defined in the f90 Manual.

---

From: [email-masked] (Mary E Zosel)
Date: Tue, 19 May 92 12:27:28 -0700

One simple reply to Q4 of Loveman's questions ... 
---
Q4:   An association directive with no  entity-list, e.g.,

                SUBROUTINE T(X,Y)

        or should it be

---

OPINION --- the first form is better for those cases where
people write simple tools which pull source files apart by
subroutines --- directives and comments ahead of the subroutine
statement are error prone for correct splitting into multiple files.
Yes - good tools have probably solved it, but this is one of those
application tools which users tend to reinvent the wheel.

   -mary-