ClangToTMac failing with _mm_broadcastsi128_si256 is invalid in C99 |
|||||
Issue descriptionClangToTMac fails to compile due to _mm_broadcastsi128_si256 intrinsic not found: https://build.chromium.org/p/chromium.fyi/builders/ClangToTMac/builds/10421/steps/compile/logs/stdio FAILED: obj/third_party/libvpx/libvpx_intrinsics_avx2/vpx_subpixel_8t_intrin_avx2.o ../../third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF obj/third_party/libvpx/libvpx_intrinsics_avx2/vpx_subpixel_8t_intrin_avx2.o.d -DV8_DEPRECATION_WARNINGS -DENABLE_NOTIFICATIONS -DENABLE_PEPPER_CDMS -DENABLE_PLUGINS=1 -DENABLE_PDF=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 -DUSE_BROWSER_SPELLCHECKER=1 -DNO_TCMALLOC -DUSE_EXTERNAL_POPUP_MENU=1 -DENABLE_WEBRTC=1 -DENABLE_EXTENSIONS=1 -DENABLE_TASK_MANAGER=1 -DENABLE_THEMES=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_PLUGIN_INSTALLATION=1 -DENABLE_SUPERVISED_USERS=1 -DENABLE_SERVICE_DISCOVERY=1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED -DCR_CLANG_REVISION=276668 -DCOMPONENT_BUILD -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORE=0 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../.. -Igen -I../../third_party/libvpx/source/config -I../../third_party/libvpx/source/config/mac/x64 -I../../third_party/libvpx/source/libvpx -Igen/third_party/libvpx -mavx2 -fno-strict-aliasing -fstack-protector -fcolor-diagnostics -arch x86_64 -O2 -g1 -isysroot /Applications/Xcode7.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -mmacosx-version-min=10.7 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Werror -Wall -Wno-unused-variable -Wpartial-availability -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-conversion -Wno-parentheses-equality -Wno-unused-function -std=c99 -c ../../third_party/libvpx/source/libvpx/vpx_dsp/x86/vpx_subpixel_8t_intrin_avx2.c -o obj/third_party/libvpx/libvpx_intrinsics_avx2/vpx_subpixel_8t_intrin_avx2.o ../../third_party/libvpx/source/libvpx/vpx_dsp/x86/vpx_subpixel_8t_intrin_avx2.c:83:18: error: implicit declaration of function '_mm_broadcastsi128_si256' is invalid in C99 [-Werror,-Wimplicit-function-declaration] filtersReg32 = MM256_BROADCASTSI128_SI256(filtersReg); ^ ../../third_party/libvpx/source/libvpx/vpx_dsp/x86/vpx_subpixel_8t_intrin_avx2.c:45:8: note: expanded from macro 'MM256_BROADCASTSI128_SI256' _mm_broadcastsi128_si256((__m128i const *)&(x)) ^ ../../third_party/libvpx/source/libvpx/vpx_dsp/x86/vpx_subpixel_8t_intrin_avx2.c:83:18: note: did you mean '_mm256_broadcastsi128_si256'? ../../third_party/libvpx/source/libvpx/vpx_dsp/x86/vpx_subpixel_8t_intrin_avx2.c:45:8: note: expanded from macro 'MM256_BROADCASTSI128_SI256' _mm_broadcastsi128_si256((__m128i const *)&(x)) ^ /b/c/b/ClangToTMac/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/4.0.0/include/avx2intrin.h:863:1: note: '_mm256_broadcastsi128_si256' declared here _mm256_broadcastsi128_si256(__m128i __X) ^ ../../third_party/libvpx/source/libvpx/vpx_dsp/x86/vpx_subpixel_8t_intrin_avx2.c:83:16: error: assigning to '__m256i' (vector of 4 'long long' values) from incompatible type 'int' filtersReg32 = MM256_BROADCASTSI128_SI256(filtersReg); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../third_party/libvpx/source/libvpx/vpx_dsp/x86/vpx_subpixel_8t_intrin_avx2.c:328:16: error: assigning to '__m256i' (vector of 4 'long long' values) from incompatible type 'int' filtersReg32 = MM256_BROADCASTSI128_SI256(filtersReg); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3 errors generated. There has been quite a lot of work regarding to AVX256 in the LLVM trunk, might be due to that. It's strange, though, that it only manifests on Mac.
,
Jul 25 2016
Okay, the explanation for the issue to be Mac-specific is this ifdef:
#if defined(__clang__)
# if __clang_major__ < 3 || (__clang_major__ == 3 && __clang_minor__ <= 3) || \
(defined(__APPLE__) && \
((__clang_major__ == 4 && __clang_minor__ <= 2) || \
(__clang_major__ == 5 && __clang_minor__ == 0)))
As Clang version now turned to be 4.0, the ifdef for an old Clang started to be valid. I am not sure why __clang_major__ on __APPLE__ could be that high (up to 5).
There're some relevant bugs, which linked from the commit that adds this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1085607
https://code.google.com/p/webm/issues/detail?id=1082
Johann, can you please suggest what do we do here? The regular Clang version reached 4.0, and there's apparently some collision between the version reported by an old Apple toolchain and the new Clang toolchain that we use in Chrome.
,
Jul 25 2016
Apparently, Apple faking __clang_major is a known pain point: http://stackoverflow.com/questions/19387043/how-can-i-reliably-detect-the-version-of-clang-at-preprocessing-time The solution seems to be relying on __apple_build_version__ being defined, rather than __APPLE__, as __APPLE__ is a sign of the code being compiled for an Apple OS rather than the sign for an Apple Clang.
,
Jul 25 2016
Here are the examples of similar checks in the Chromium repos: https://cs.chromium.org/chromium/src/third_party/libwebp/dsp/enc_neon.c?q=__apple_build_version__&sq=package:chromium&l=848&dr=C https://cs.chromium.org/chromium/src/third_party/protobuf/objectivec/GPBDictionary.m?q=__apple_build_version__&sq=package:chromium&l=57&dr=C
,
Jul 25 2016
Fix posted on Gerrit: https://chromium-review.googlesource.com/#/c/362992/
,
Jul 25 2016
Adding more libvpx folks to CC.
,
Jul 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/webm/libvpx/+/91369fd9b7be7ccbc22b3b296a7ea601fb59f8d7 commit 91369fd9b7be7ccbc22b3b296a7ea601fb59f8d7 Author: Ivan Krasin <krasin@chromium.org> Date: Mon Jul 25 19:11:02 2016 Fix compilation error under Clang 4.0. The LLVM trunk has reached 4.0 and now __clang_major__ is not enough to distinguish between old XCode Clang and the new 'real' Clang. Using __apple_build_version__ allows to make this distinction. BUG= chromium:631144 Change-Id: I0b6e46fddfe4f409c7b7e558bda34872e60ee2d9 [modify] https://crrev.com/91369fd9b7be7ccbc22b3b296a7ea601fb59f8d7/vpx_dsp/x86/vpx_subpixel_8t_intrin_avx2.c
,
Jul 25 2016
Rolling deps at https://codereview.chromium.org/2178123002/ Once it's there, we'll see if the issue is really fixed on Mac (I really hope so)
,
Jul 26 2016
Fixed: https://build.chromium.org/p/chromium.fyi/builders/ClangToTMac%20%28dbg%29/builds/5979
,
Jul 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/webm/libvpx/+/eb66904d7c97494f5181a30319a1c56bd7c1380e commit eb66904d7c97494f5181a30319a1c56bd7c1380e Author: Ivan Krasin <krasin@chromium.org> Date: Mon Jul 25 19:11:02 2016 Fix compilation error under Clang 4.0. The LLVM trunk has reached 4.0 and now __clang_major__ is not enough to distinguish between old XCode Clang and the new 'real' Clang. Using __apple_build_version__ allows to make this distinction. BUG= chromium:631144 Change-Id: I0b6e46fddfe4f409c7b7e558bda34872e60ee2d9 [modify] https://crrev.com/eb66904d7c97494f5181a30319a1c56bd7c1380e/vpx_dsp/x86/vpx_subpixel_8t_intrin_avx2.c |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krasin@chromium.org
, Jul 25 2016