Invalid arithmetic on void pointers

[nenadv]

A few tests in upc-sematic test suite are passing in harness with clangupc but should fail:

[upc-semantic-checks/invalid-local-ptr-to-void-arith_st04] FAILED: expect fail  
[upc-semantic-checks/invalid-local-ptr-to-void-arith] FAILED: expect fail but   
[upc-semantic-checks/invalid-sizeof-shared-void_st04] FAILED: expect fail but   
[upc-semantic-checks/invalid-sizeof-shared-void] FAILED: expect fail but passed 
[upc-semantic-checks/invalid-sizeof-void_st04] FAILED: expect fail but got      
[upc-semantic-checks/invalid-sizeof-void] FAILED: expect fail but got warning 

I don't know if this is related to 3.4 update or this never worked the way it was supposed. For example this should produce an error:

void *x;
..
y = x + 1;

However, clangupc does not treat this as an error. It treats it as an error/waring if "-pedantic-errors" option is specified. GUPC produces an error.

Note that this error is masked by the options we use when we test clangupc with intrepid test suite. A -pedantic-errors switch together with -Wall -Wextra -Werror is used that makes this warning an error and test checking gets the right result.

This error should not be masked by switches.

[swatanabe]

On 02/05/2014 05:31 PM, Nenad Vukicevic wrote:

void *x;
..
y = x + 1;

However, clangupc does not treat this as an error. It treats it as an error/waring if "-pedantic-errors" option is specified. GUPC produces an error.

This code is incorrect, but clang accepts it as an extension. It has nothing to do with UPC. I think we agreed to leave this alone last time this issue came up.

[nenadv]

Yes, as comment in one of those tests states:

/* The consensus of the UPC community seems to be that
   arithmetic on (void *) pointers is a compilation error.  */

we probably need to make clangupc the same as BUPC and GUPC.

Note that while upc2c does not produce warning, gcc will produce one once translated code is compiled.

[swatanabe]

On 02/05/2014 05:51 PM, Nenad Vukicevic wrote:

Yes, as comment in one of those tests states:

/* The consensus of the UPC community seems to be that
   arithmetic on (void *) pointers is a compilation error.  */

we probably need to make clangupc the same as BUPC and GUPC.

Note that while upc2c does not produce warning, gcc will produce one once translated code is compiled.

Nevertheless, this is the behavior that clang chose. I don't think it's reasonable to change something that's has nothing to do with UPC and which appears to be intentional on the part of the clang team.

[gary-funck]

The UPC version 1.3 specification states:

6.4.2 Pointer-to-shared arithmetic
Constraints
1 No binary operators shall be applied to one pointer-to-shared and one pointerto-local.
2 Relational operators (as defined in [ISO/IEC00 Sec 6.5.8]) shall not be applied to a pointer-to-shared with incomplete type.

Thus, the "consensus" was changed into the "rule" during the most recent spec. update.

Since those are constraints then it is a compilation error if the constraint is violated. Thus, for UPC those usages should be diagnosed as errors. If it is not practical to do so, we will have to log this as a known limitation.

The way this is handled in GUPC is that during options processing initialization, ' warn_pointer_arith' is asserted and then this option is set up so that this particular warning is diagnosed as an error. This is only done if -fupc has been asserted on the command line, thus it is only done for UPC compilations. I don't know if Clang has an internal mechanism like this, but this is a uniform way to handle this case without significant change to the compiler.

[swatanabe]

On 02/06/2014 06:44 AM, gary-funck wrote:

The UPC version 1.3 specification states:

6.4.2 Pointer-to-shared arithmetic
Constraints
1 No binary operators shall be applied to one pointer-to-shared and one pointerto-local.
2 Relational operators (as defined in [ISO/IEC00 Sec 6.5.8]) shall not be applied to a pointer-to-shared with incomplete type.

I don't see how this is relevant. The test case uses void * (which is not a pointer-to-shared).

[gary-funck]

I don't see how this is relevant. The test case uses void * (which is not a pointer-to-shared).

Sorry, I missed the main point of this PR. Does Clang UPC properly diagnose the arithmetic on (shared void ) as an error? If so, then it looks like we drop back to "consensus". Note that in GUPC we did handle both arithmetic on (void ) and (shared void *) as an error, using the technique that I mentioned in my reply.

[nenadv]

Added as known issues. Will not fix as the warning is correct.