Created attachment 685 [details] vreinterpretq_u64_f64 workaround The vreinterpretq_u64_f64 work-around introduced in Bug 907 fails to build here on a Android/Aarch64/Clang toolchain. The problem is that it is enclosed in this #if : #if (EIGEN_COMP_GNUC_STRICT && defined(__ANDROID__)) || defined(__apple_build_version__) Here, my toolchain is using Clang, so EIGEN_COMP_GNUC_STRICT is false, so the workaround isn't used. As a result, I get compiler errors complaining that vreinterpretq_u64_f64 isn't defined. Since it's too tricky to try to isolate the exact preprocessor check determining whether vreinterpretq_u64_f64 is missing, I would like to propose a different approach: just always define vreinterpretq_u64_f64, but as a lower-priority overload so if it's already defined by arm_neon.h, then our overload won't be used. One way to do that is to templatize the workaround, since template overloads have lower priority. Patch attached, OK to push? Further changes made in this patch include the removal of "static" since we're in a header file, and of "__extension__" since I couldn't see any useful effect of it, even with -pedantic as was its original motivation in bug 907, and of __inline __attribute__ ((__always_inline__)) as this trivial template function is already inline and I don't have any data to suggest that that's not enough.
Created attachment 686 [details] vreinterpretq_u64_f64 workaround
OK, pushed, but let me know if not OK. https://bitbucket.org/eigen/eigen/commits/c33b505f4267a442bac284c179acaf9a26992afa
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/1186.