Clang UPC does not diagnose THREADS present in more than one dimension

[PHHargrove]

This issue is a report of the known failure of clang-upc to diagnose the two illegal typedefs in bug3057.upc of the Berkeley UPC testsuite:

  // These are illegal in dynamic threads environment:
  typedef shared int (*pc)[THREADS][ 13  ][THREADS];
  typedef shared int (*pd)[THREADS][ii+jj][THREADS];

I am testing a possible fix now to ensure it does not cause any regressions.

[PHHargrove]

I am testing a possible fix now to ensure it does not cause any regressions. Alas clang-upc now crashes on at least one test case. I will look at this again it/when I have time.

[PHHargrove]

New version (https://github.com/PHHargrove/clang-upc/commit/f1a9cd9b4cd28b0b2a1458fb41a979f99cb32ac5) - seems to work correctly now with no crashes or other regressions.

The approach taken is to check in SemaType while the multi-dimensional array is being constructed. This seemed easier than checking in SemaDecl, when the type is already fully constructed, but is also perhaps less natural than checking there. Thoughts?

[nenadv]

I tried a small test program:

#include <upc.h>

typedef shared int (*pc)[THREADS][ 13  ][THREADS];
typedef shared int (*pcok)[THREADS][ 13  ][5];

pc x;

int main ()
{
}

which reports an error:

issue38.upc:3:22: error: variably modified type declaration not allowed at file scope
typedef shared int (*pc)[THREADS][ 13  ][THREADS];
                     ^
issue38.upc:6:4: error: variably modified type declaration not allowed at file scope
pc x;
   ^
2 errors generated.

Is this maybe VLA related? As THREADS is just another variable it does allow it in the function content?

[nenadv]

bug3057 does have typedefs inside the function scope and clang-upc does not raise an error.

[PHHargrove]

My best guess is that the difference between Nenad's example of two comments back and bug3057 is related to VLA. I suspect that the new example is rejected by some VLA-related check before my new code has a chance to reject it. I can look at moving my new detection code earlier, but if that doesn't work I am not sure how to proceed.

[PHHargrove]

It looks unlikely that I will have time this week to work on this again. That actually makes it unlikely that I'll be able to finish this at all. So, I will drop the "assignment". Hopefully the partial work in my branch is useful to whoever has time to follow up on this.

[swatanabe]

clang-upc is more permissive about typedefs than it is about variables.

If these typedef are considered illegal, then the following should also be illegal, since it's covered by the same clause in the standard:

typedef shared int inner[2];

But, this type can appear in UPC programs (although it might not be written out explicitly).

Consider

shared int a[THREADS][2];

Then the type of "a[0]" (which is a perfectly valid expression) is shared int[2], which we've just decided is an illegal array type.

[nenadv]

These tests form upc-semantics all fail (but used to pass at some point in time) - tests actually pass but should fail to compile.

dyn-array-dim-not-simple-multiple-of-threads.upc

shared [*] int A[THREADS+1];

dyn-threads-more-than-once.upc

shared int A[THREADS*THREADS];

dyn-threads-with-indef-block-size.upc

shared [] int A[THREADS];

[nenadv]

Strike the previous message. We are having some issues with running the tests and the above compiled static.