Define GASP (Global Address Space Performance monitoring) support as an optional UPC library

[Former user]

Originally reported on Google Code with ID 24 ``` This proposal is responsive to issue 15.

15. Should GASP's "#pragma pupc on" and "#pragma pupc off" be defined in the specification?

This proposal recommends that the "pupc" pragmas and the GASP library API are defined in an optional library. This library is somewhat unusual in that the UPC compiler must target the library API and implement the "pupc" pragmas in the compiler front-end. That said, the GASP API is potentially just one of many possible performance measurement API's and supporting libraries. Thus, GASP support is best described in an optional library specification.

```

Reported by `gary.funck` on 2012-05-21 22:34:51

[Former user]

``` I agree with the idea that the UPC spec's optional libraries section would be an appropriate place to document/standardize the pragmas used to interact between the UPC source code and the profiling implementation, with cooperation of the compiler. ```

Reported by `[e-mail]` on 2012-05-21 23:44:02

[Former user]

``` Pragmas are by their nature a hook for implementation-defined behavior, as defined by ISO C 6.5.10: A preprocessing directive of the form: # pragma pp-tokensopt new-line ... causes the implementation to behave in an implementation-defined manner. ... Any such pragma that is not recognized by the implementation is ignored.

Syntactically pragmas are not an extension to UPC, they are standard-conformant C99. They are by their very nature implementation-dependent, and therefore would be inappropriate for inclusion in the language specification (at least in that syntactic form).

There is already a published specification for GASP that clearly defines the semantics of these pragmas, which incidentally extend beyond the confines of UPC to include several other C-based parallel software (shmem, MPI, OpenMP etc). The semantics of all pragmas in UPC are implementation-defined, and in the case of these pragmas a GASP-compliant UPC compiler can "define" the semantics by simply referencing the GASP specification. I see no motivation to codify this in the specification for the base language or otherwise tie the GASP spec to the UPC spec.

I move this issue be resolved WONTFIX. ```

Reported by `danbonachea` on 2012-05-31 08:07:43

[Former user]

``` I concur with WONTFIX, but will point out that defining GASP as an optional library would carry with it the possibility that at some point GASP support might be considered for inclusion into the UPC required library. Thus, vendors might be more inclined to provide support for GASP than if it retains its current status as part of the independently defined GASP project and support library. Also, as indicated in this issue, to support GASP some compiler help is required, which makes this library distinctive. ```

Reported by `gary.funck` on 2012-06-15 02:32:40

[Former user]

```

defining GASP as an optional library

... would make no sense because it has no library component, nor any language-level semantics aside from the #pragmas, which as discussed above don't belong in the spec.

at some point GASP support might be considered for inclusion into the UPC required

library.

I believe this would be a serious mistake since it implies that implementations would be non-conformant unless GASP support is enabled. I can't speak for other implementations but BUPC's GASP implementation has a significant performance impact, and is disabled by default unless the user enables profiling.

In any case we seem to be in agreement that no spec change is indicated at this time so closing the issue.

```

Reported by `danbonachea` on 2012-06-15 03:01:28 - Status changed: `WontFix`

[Former user]

``` While I agree w/ Dan on the point that GASP is NOT a library, I also understand Gary's viewpoint that "annexing" the GASP specification as an appendix of the UPC specification

• might* be a Good Thing to help encourage interoperability of multiple UPC compiler/runtime implementations with multiple performance tools.

The major point to be made AGAINST annexing GASP to UPC, is that GASP is intended to cover non-UPC parallel programming environments (as Dan already observed). So, at best would could codify in an appendix the subset of GASP that was "recommended" (or even required if we would ever go so far) for UPC compliance. Having just agreed that we rather just cite ISO C99 than repeat it, I would suggest that repeating the GASP specification is also unwarranted/unwanted.

So, on balance I vote against any GASP-related additions to the UPC spec at this time AND in the future. [but do appreciate that Gary raised the issue for discussion] ```

Reported by `[e-mail]` on 2012-06-15 03:55:03

[Former user]

``` Dan/Paul, thanks for the follow up.

In passing: although I did catalog many of the open issues, unless otherwise stated, my main purpose was simply to put on record various questions/issues that either I have encountered directly or that have been related to me by other UPC users and compiler/runtime developers.

On this specific issue: I agree with the consensus that has formed, which is not to address GASP in the UPC specification.

```

Reported by `gary.funck` on 2012-06-15 04:22:36

[Former user]

``` Mass update to closed issue status ```

Reported by `danbonachea` on 2012-06-15 18:38:27 - Status changed: `Rejected`

[Former user]

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