[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