Drop strict/relaxed qualifiers when checking type compatibility with generic pointers-to-shared.

Issue #20 new
Former user created an issue

Originally reported on Google Code with ID 20

This proposal is responsive to language issue 50.

50. Re: advantages of defining upc_threadof and related functions as operators, an
operator is capable of adapting to a wider variety of argument types. For example,
this program results in a warning ("‘upc_threadof’ discards ‘strict’ qualifier from
pointer target type") when compiled with GCC/UPC:

  strict shared int a;
  thread = upc_threadof (&a);

Although this warning may not be mandated by the standard, "C" compilers will typically
warn about this sort of usage, and there is no obvious work-around because the function
argument type matching rules will dictate the nature of this check.

This proposal would mandate that non-generic pointers-to-shared whose target type is
further qualified by either 'strict' or 'relaxed' are compatible with generic pointers-to-shared
and can be converted without a cast that removes the 'strict' or 'relaxed' qualifiers.
 Thus, in the example shown above, the compiler will accept the call to the upc_threadof()
function without complaint.

Reported by gary.funck on 2012-05-21 16:52:27

Comments (7)

  1. Former user Account Deleted

    ``` I would argue that dropping this check might not be safe in general. For instance, passing a strict-qualified pointer-to-shared into the collective operations will NOT magically produce strict semantics for the data accesses within the collectives. So, in that case I would want the warning to appear unless the user has supplied a cast to silence the warning and thus "sign the contract" so-to-speak.

    I think that a better response to the upc_threadof() example would be the proposal in issue #19 (in the issue tracker, not the original list) to make certain functions into operators. ```

    Reported by `phhargrove@lbl.gov` on 2012-05-23 19:59:42

  2. Former user Account Deleted

    ``` I would like to see this issue resolved in the 1.3 specification either by somehow relaxing type compatibility checks or defining upc_trheadof and related functions as operators.

    As noted in Dan's reply to issue #19: http://code.google.com/p/upc-specification/issues/detail?id=19#c9 I agree in principle that re-defining upc_threadof and related functions as operators presents an "uncomfortable" solution, because it fixes the issue just for those commonly used operations, but other user-written functions receive no similar benefit. I just don't know how we can achieve the goal by relaxing the type compatibiliy rules.

    ```

    Reported by `gary.funck` on 2012-07-03 00:00:45 - Labels added: Milestone-Spec-1.3

  3. Former user Account Deleted

    ``` Set default Consensus to "Low". ```

    Reported by `gary.funck` on 2012-08-19 23:26:19 - Labels added: Consensus-Low

  4. Former user Account Deleted

    ``` Mass change "Accepted" issues which haven't seen activity for over a month back to "New", for telecon discussion. ```

    Reported by `danbonachea` on 2012-10-04 11:36:12 - Status changed: `New`

  5. Former user Account Deleted
    deferred to 1.4 along with issue 19 at the 11/29 telecon
    

    Reported by danbonachea on 2012-11-29 19:23:24 - Labels added: Milestone-Spec-1.4 - Labels removed: Milestone-Spec-1.3

  6. Log in to comment