================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
