[libcxx-commits] [clang] [libcxx] [libc++] Don't dispatch find to wmemchr under -fshort-wchar (PR #203621)
Louis Dionne via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Jun 16 11:58:50 PDT 2026
================
@@ -127,7 +127,13 @@ _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14 _Tp* __find(_Tp* __first, _T
return __last;
}
# if _LIBCPP_HAS_WIDE_CHARACTERS
- else if constexpr (sizeof(_Tp) == sizeof(wchar_t) && _LIBCPP_ALIGNOF(_Tp) >= _LIBCPP_ALIGNOF(wchar_t)) {
+ // __builtin_wmemchr lowers to a libc call that walks native-sized wchar_t
+ // elements. Only take this path when wchar_t still has its platform-native
+ // size and alignment. Otherwise (e.g., under -fshort-wchar) fall through to the
+ // vectorized integral path, which honors the current wchar_t size.
+ else if constexpr (sizeof(_Tp) == sizeof(wchar_t) && _LIBCPP_ALIGNOF(_Tp) >= _LIBCPP_ALIGNOF(wchar_t) &&
----------------
ldionne wrote:
Is there a reason why we don't simply do `sizeof(_Tp) == sizeof(__native_wchar_t) && _LIBCPP_ALIGNOF(_Tp) >= _LIBCPP_ALIGNOF(__native_wchar_t)` directly?
Also, it seems like a better fix might be to do the check inside `__constexpr_wmemchr`, which is where we dispatch to the underlying (potentially libc) implementation, and that's where the `wchar_t` representation mismatch happens.
https://github.com/llvm/llvm-project/pull/203621
More information about the libcxx-commits
mailing list