Closed gary-funck closed 10 years ago
Here is a test case.
// Tester for "issue 11" compliance: PTS-to-integer conversion is legal
// Copyright 2013, The Regents of the University of California,
// through Lawrence Berkeley National Laboratory (subject to
// receipt of any required approvals from U.S. Dept. of Energy)
// See the full license terms at
// http://upc.lbl.gov/download/dist/LICENSE.TXT
#include <upc.h>
#include <stdio.h>
shared int x;
shared double y;
int main(void) {
int i = (int) &x; // initialization
i = (int)&y; // assignment
if (!MYTHREAD) // comparison:
puts((i == (int)&x) ? "FAIL" : "PASS");
return 0;
}
I would prefer to guarantee that for any sufficiently large integer type, (shared T*)(intpts_t)sp == sp. Clang has __int128 so such an integer should always exist.
Yes, that is tempting and there is some logic to that solution. We're gravitating towards making this equivalent to upc_addrfield. Hold up on making any change --- let me prototype this on GUPC to better understand the pros/cons.
The UPC 1.3 Specification states that a UPC compiler should support an implementation-defined conversion from pointer-to-shared to integer. http://code.google.com/p/upc-specification/issues/detail?id=11 [^]
Here is the summary.
1) Is arithmetic on (void ) and (shared void ) an error? Some implementations of UPC currently define arithmetic on (shared void *) as erroneous. BUPC thinks it is ... and GCC/UPC has now followed suit, but what does C99 say?
Answer: Yes, this is an error.
2) Is conversion from a pointer?to?shared to an integer allowed? BUPC thinks it is and does something, GCC/UPC issues an error. If it is defined in the language, what is the definition? (Note that on 32?bit targets, a shared pointer might be 64 bits, and 128 bits on a 64?bit target.)
Answer: Conversion from a pointer?to?shared to an integer is allowed but the result is implementation-defined.
Clang UPC should be changed to provide a conversion from a PTS to an integer. We will likely make this have the same effect as upc_addrfield().