Layout specifier '[*]' interpretation in typedef

Issue #2 new
Former user created an issue

Originally reported on Google Code with ID 2

Constraint 6.5.1.1-14 states the following:

    14 If the layout qualifier is of the form [ * ],
    the shared object is distributed as if it had a block size of
    ( sizeof(a) / upc_elemsizeof(a) + THREADS - 1 ) / THREADS,
    where a is the array being distributed.

As described in Berkeley bug report 856
(https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=856#c3)
the specification does not explicitly state the required
interpretation for the following chain of typedef's.

    typedef int I;
    typedef I J[10];
    typedef shared [*] J K[10];
    typedef K L[10];
    K k;
    L l;

If '[*]' is bound to a specific block size when the typedef 'K'
is declared, then it will have the value: ceiling (100 / THREADS).
In this interpretation the block sizes of both the types K
and L are necessarily equal.  Therefore, the arrays 'k' and 'l'
have the same block size.

However, if '[*]' is allowed to propagate to the declaration of
L before it is evaluated, then the resulting block size of L
is: ceiling (1000 / THREADS).

The proposed interpretation is the first one: where '[*]'
is evaluated at the point of its use in a declaration
or type definition.

Note: this is the consensus interpretation of the Cray, SGI, MuPC,
and GCC/UPC compilers.

We propose that an additional constraint is added to
the specification which states the following:

    If the layout qualifier of the form '[*]' is present in a
    type definition, its value is calculated according to
    Constraint 14.  It is this value that will be used when the
    type definition is referenced in subsequent declarations.

The following example will be added in the same section.

    EXAMPLE:

    Both the types K and L below have the same block size,
    which is equal to: ceiling (100 / THREADS).

        typedef int I;
        typedef I J[10];
        typedef shared [*] J K[10];
        typedef K L[10];

Reported by gary.funck on 2012-03-09 18:34:56

Comments (8)

  1. Former user Account Deleted

    ``` Berkeley endorses this interpretation/clarification.

    BUPC is not listed in the compilers having this "consensus interpretation" because we do not currently compile this code correctly under either this interpretation or the alternative of "late binding" the layout qualifier. This is a BUPC bug, and NOT an attempt to support any alternative to this proposed clarification.

    In my opinion the clarity of the proposed example would be improved by eliminating "typedef int I" and instead using "int" explicitly in the typedef for J.

    -Paul ```

    Reported by `phhargrove@lbl.gov` on 2012-03-09 19:15:29

  2. Former user Account Deleted

    ``` Paul suggests: <<the clarity of the proposed example would be improved by eliminating "typedef int I" and instead using "int" explicitly in the typedef for J.>>

    I agree.

    ```

    Reported by `gary.funck` on 2012-03-09 21:36:48

  3. Former user Account Deleted

    ``` I support this clarification.

    Anyone else have a view, or should we move to put this in the 1.3 draft?

    ```

    Reported by `wwc@uuuuc.us` on 2012-03-16 11:43:56

  4. Former user Account Deleted

    ``` Cray UPC agrees that the [*] should be evaluated when it is first seen and this clarification should go in the 1.3 draft unless the [*] block size is completely dropped. The evaluation point still should be clarified if it is merely deprecated -- see Issue 8. ```

    Reported by `johnson.troy.a` on 2012-03-19 19:18:37

  5. Former user Account Deleted

    ``` One approach regarding the decision to move to the 1.3 draft, it sounds like we have a quorum. Perhaps the status can be changed to "Fixed" (for lack of something better). This status can then be upgraded to "Done" once the issue resoluation is implemented in the 1.3 specification.

    ```

    Reported by `gary.funck` on 2012-03-19 20:09:11

  6. Former user Account Deleted

    ``` I agree that Fixed and then Done makes sense for changes to the draft. Also, WontFix seems most appropriate for any issue that can be resolved without changes.

    I'll try it out with this bug... ```

    Reported by `johnson.troy.a` on 2012-03-23 17:35:38 - Status changed: `Fixed`

  7. Former user Account Deleted

    Reported by `gary.funck` on 2012-07-06 21:04:02 - Labels added: Milestone-Spec-1.3

  8. Former user Account Deleted
    This closed issue was superseded by the ratified change for issue 71, so changing this
    issue status to rejected.
    

    Reported by danbonachea on 2012-11-11 01:26:25 - Status changed: Rejected

  9. Log in to comment