openshmem-org/tests-uh

OpenSHMEM Test Suite

tests-uh's Issues

Memory Allocation incorrect in test

Not sure, how the "4" in the memory allocation came - should be N

tests-uh/feature_tests/C/test_shmem_put.c

Line 142 in 15d685d

dest8 = (char *) shmem_malloc (4 * sizeof (*dest8));

Inaccessibility is a lie

The feature_tests/Fortran/accessibility/test_shmem_acc_mem_04_*.f90 unit tests check whether the compiler does not place the following variable in the data or bss segment:

real*8            :: remote_dest(2)

However, it's totally fine for the compiler to put a program-level variable (i.e. lifetime is the duration of the full program) like this into the data segment and it turns out that ifort does just this. The *05* tests are similar, except the given variable is ALLOCATABLE, which is a more reasonable test of inaccessibility.

I considered proposing to move the *04* tests to "error" tests, but I don't think they are even valid error tests. Can we delete them?

Use of "_" to prefix OSHMEM constant names

I notice that to get these tests to compile in Open MPI's OpenSHMEM implementation, I had to make the following changes:

diff --git a/feature_tests/C/test_shmem_query.c b/feature_tests/C/test_shmem_que
index 3c54de2..a611240 100644
--- a/feature_tests/C/test_shmem_query.c
+++ b/feature_tests/C/test_shmem_query.c
@@ -65,7 +65,7 @@
 int
 main ()
 {
-    char name[_SHMEM_MAX_NAME_LEN];
+    char name[SHMEM_MAX_NAME_LEN];
     int major_ver, minor_ver;
     int me;
 
@@ -79,7 +79,7 @@ main ()
       shmem_info_get_version (&major_ver, &minor_ver);
       shmem_info_get_name (name);
 
-      if (major_ver == _SHMEM_MAJOR_VERSION) {
+      if (major_ver == SHMEM_MAJOR_VERSION) {
           PRINT_VER("Major","Passed");
       }
       else {
@@ -87,7 +87,7 @@ main ()
           fail_count++;
       }
 
-      if (minor_ver == _SHMEM_MINOR_VERSION) {
+      if (minor_ver == SHMEM_MINOR_VERSION) {
           PRINT_VER("Minor","Passed");
       }
       else {
@@ -95,7 +95,7 @@ main ()
           fail_count++;
       }
 
-      if (strlen (name) < _SHMEM_MAX_NAME_LEN) {
+      if (strlen (name) < SHMEM_MAX_NAME_LEN) {
           PRINT_NAME("Passed");
       }
       else {
diff --git a/feature_tests/C/test_shmem_synchronization.c b/feature_tests/C/test
index df47afb..e2e9a1f 100644
--- a/feature_tests/C/test_shmem_synchronization.c
+++ b/feature_tests/C/test_shmem_synchronization.c
@@ -125,7 +125,7 @@ main (void)
         shmem_barrier_all ();
 
         if (me == 1) {
-            shmem_long_wait_until (dest, _SHMEM_CMP_NE, 9L);
+            shmem_long_wait_until (dest, SHMEM_CMP_NE, 9L);
             printf ("Test for explicit conditional wait: Passed\n");
         }
 

I'm not an OpenSHMEM expert. Is Open MPI incorrect in not having the "_"-prefixed versions of these names? Or are these tests incorrect?

Thanks!

long double datasize issues for shmem_put_global tests

@tonycurtis The datasize for long double is assumed as 128b on the feature_tests/C/test_shmem_put_globals.c tests. It seems the long double datasize depends on the compiler precision. It can vary from 64b to 128b. Using long double variables for testing shmem_put128 doesn't seem right.

Let me know what you think.

Why are some tests expected to timeout?

I notice in testrunner.pl (and the various .conf files) that some tests are expected to timeout.

I'm curious: why are tests expected to time out / why does testrunner.pl report those tests as succeeding?

Thanks!

@jdinan @tonycurtis

Invalid char comparison to negative value

In tests like test_shmem_zero_get.c, there is an invalid comparison between a char and a negative number.

tests-uh/feature_tests/C/test_shmem_zero_get.c

Line 197 in 15d685d

if (dest8[i] != -9) {

Depending on the architecture's implementation of char, the test could fail. According to The C Programming Language, the implementation of char has implementation defined limits. The portable way to do this would be to use signed char.

Test cases failing on Power PC because of this.