cce/8.7.6 compilation failures about openaccv-v

[jgphpc]

For cce, i had to modify acc_testsuite.h:

diff --git a/Tests/acc_testsuite.h b/Tests/acc_testsuite.h
index f7a4861..3362ef0 100644
--- a/Tests/acc_testsuite.h
+++ b/Tests/acc_testsuite.h
@@ -26,7 +26,11 @@
 long long n = ARRAYSIZE;
 #define PRECISION   1e-8
 typedef double real_t;
+
+#ifndef _CRAYC
 typedef enum { false, true } bool;
+#endif
+
 #define ARRAYSIZE_NEW 1024
 #define ARRAYSIZE_SMALL 10

[utimatu]

CC-10321:
I haven't taken the time to review all of these, but I cannot find any issues with the formats of the atomics. The format for the capture in the specific one you have shown the error for is found on page 36 of the OpenACC specifications and is the last item in the list of valid capture statements: v = x = expr binop x. The atomic formats allowed in the spec are the same from 2.0 on, so it is probably an issue with Cray if they are not working. If any of the tests specifically seem to have non-conforming forms of the atomic statement, please bring them to my attention. It is tricky work to evaluate 300+ different valid formats of the atomic construct.

CC-10299:
The default(present) clause that it is complaining about was not included in the specifications until version 2.5, after Cray stopped updating for new OpenACC features, so the fact that it is not compiling happy is not surprising.

CC-10302:
This one I cannot explain. The auto clause is valid on a loop construct, and since I don't see any restrictions otherwise, I assume that it can also be applied to a parallel loop construct. It was in the specifications in 2.0 and was valid in that context. My thoughts are that this might be a Cray issue.

acc_copyin_async, acc_copyout_async, acc_create_async, acc_delete_async, acc_memcpy_from_device_async, acc_memcpy_to_device_async, acc_update_device_async, acc_update_self_async:
These runtime routines were all added in the 2.5 version which added async data routines. So I'm not surprised that Cray doesn't support these either.

acc_copyin, acc_create, acc_malloc:
Each of these was already included in the OpenACC 2.0 spec. I find it interesting that the three allocation routines are having problems but not the acc_copyout, acc_delete, or the acc_free. Do you think you could give me the exact errors for these? If the issue is undefined ref, what reference is undefined in these?

acc_get_default_async, acc_set_default_async:
OpenACC 2.0 did not even have the acc-default-async-var ICV. So having routines that could modify them would also not work properly with a pure 2.0 implementation.

I really appreciate the work you did, and if you are willing, I would love to see the full list of results that you were able to gather on the Cray compiler. As they do not support 2.5 and this project is a 2.5+ testsuite, we have not looked into the performance of Cray on the testsuite, but I would be curious to see the results anyway.

[jgphpc]

My list is here: https://docs.google.com/spreadsheets/d/178GkplDnPll9UoMBYcZPdsQDXxLZ5waKy7fZOyl_dEU/edit?usp=sharing

I will add results on the fly and reply to your question.
I agree with you, cce is not a primary target now.

[ajarmusch]

Hi,
Thank you for bringing this issue up at the time. Since Cray no longer supports C/C++ at the moment. We are going to close this issue and hope you will continue testing with the HPE Cray Fortran compiler as we are currently doing.