Source: ocl-icd Version: 2.2.3-1 Severity: important Hi,
ocl-icd FTBFS on mips64el due to the failure of the test "5: Our dummy ICD through our ICD loader" The full log is here, but doesn't contain much detail: http://mips64el.debian.net/debian/buildlog/o/ocl-icd_2.2.3-1/ocl-icd_2.2.3-1_mips64el-20141231-1651.build The tail of testsuite.log contains: > 83 : clSetMemObjectDestructorCallback > 84 : clCreateUserEvent > 85 : clSetUserEventStatus > 86 : ./testsuite-standard.at:48: exit code was 139, expected 0 > 5. testsuite-standard.at:45: 5. Our dummy ICD through our ICD loader > (testsuite-standard.at:45): FAILED (testsuite-standard.at:48) I had a look at the segfault and it appears the stack was being corrupt by some dodgy function calls in the test. The dummy ICD test attempts to call all the OpenCL functions using a dummy ICD but for simplicity calls them with only 2 arguments (see run_dummy_icd_gen.c + run_dummy_icd_weak_gen.c) Function 86 in the list is clEnqueueReadBufferRect (found in ocl_icd_loader_gen.c). The key property of this function is that it has a 32-bit integer parameter beyond the 8th argument. The MIPS n64 ABI says that this argument must be passed on the stack and sign extended to 64-bits. To ensure this, GCC inserts a load and store to sign extend the value during the call: RETURN(((struct _cl_command_queue *)command_queue)->dispatch->clEnqueueWriteBufferRect but because the ICD test only passes 2 arguments instead of the required number, the above line ends up corrupting some random part of the previous function's stack space. Clearly the "correct" way of fixing this is to pass the correct number of arguments, but if that introduces too much complexity you could just disable the test on mips64* due to the ABI being incompatible with it. Thanks, James -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
