| Message ID | CA+=Sn1=UJD_o2UoRcO8bcHH9uhS5SYHW17iO-iC_JkYWgw-wiw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Index: testsuite/gcc.dg/atomic/c11-atomic-exec-5.c =================================================================== --- testsuite/gcc.dg/atomic/c11-atomic-exec-5.c (revision 243959) +++ testsuite/gcc.dg/atomic/c11-atomic-exec-5.c (working copy) @@ -24,7 +24,7 @@ | FE_OVERFLOW \ | FE_UNDERFLOW) -#if defined __alpha__ +#if defined __alpha__ || defined __aarch64__ #define ITER_COUNT 100 #else #define ITER_COUNT 10000
Since AARCH64 does not have a native 128bit atomics, this testcase can take a long time with the default iteration count on a "fast" multi-core machine. This is because the thread which incrementing the counter is not able to acquire the mutex before the other thread has already acquired it. I had put the analysis in PR 59305 also if someone wants to improve libatomic. So this patch decreases the count down to 100 which should be enough time spent in the atomic loop to catch problems. Committed after a bootstrap/test on aarch64-linux-gnu (both ThunderX - CN88xx and ThunderX 2 CN99xx). Thanks, Andrew Pinski ChangeLog: * gcc.dg/atomic/c11-atomic-exec-5.c: Lower ITER_COUNT to 100 for AARCH64.