Adding these tests to math/libm-test.inc's cacosh_test gives upto 770 ULPs for the long double tests: TEST_c_c (cacosh, 0.3, 0.4, 0.405112337178030872507338405200229579L, 1.29016676450309079292712537938218583L); TEST_c_c (cacosh, -0.3, 0.4, 0.405112337178030872507338405200229579L, 1.85142588908670244553551800389731705L); TEST_c_c (cacosh, 0.3, -0.4, 0.405112337178030872507338405200229579L, -1.29016676450309079292712537938218583L); TEST_c_c (cacosh, -0.3, -0.4, 0.405112337178030872507338405200229579L, -1.85142588908670244553551800389731705L); the float and double tests pass, just long double has this problem.
Suspended until somebody comes up with a patch.
The tests given in this bug take the double constants 0.3 and 0.4 and convert them to long double. The results of cacoshl appear to be within a few ULPs of what is expected for those particular long double values, whereas the expectations given in this testcase are the results for infinite-precision constants 0.3 and 0.4 (as opposed to those for values rounded to 53 bits then extended to 64 bits, or rounded directly to 64 bits) - and when your inputs differ by 11 bits from what they were intended to be, 770 ULPs is hardly an unexpected error. So this is not a correct test and there is no sign of undue inaccuracy here (I don't think it's yet expected for complex functions to be last-bit-accurate correctly rounded).