Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Missing definition of FMT_BUILTIN_CLZ on Clang-CL #3213

Closed
Epixu opened this issue Nov 30, 2022 · 3 comments
Closed

Missing definition of FMT_BUILTIN_CLZ on Clang-CL #3213

Epixu opened this issue Nov 30, 2022 · 3 comments

Comments

@Epixu
Copy link

Epixu commented Nov 30, 2022

When building on latest (Clang 15.0.1 with MSVC-like command-line) Clang-CL I encounter this error:

format.h(3152,40): error : use of undeclared identifier 'FMT_BUILTIN_CLZ'
    if (leading_xdigit > 1) f.e -= (32 - FMT_BUILTIN_CLZ(leading_xdigit) - 1);

Introduced in this commit (i think, either way, its recent)
No other compiler seems to complain

@dodheim
Copy link

dodheim commented Nov 30, 2022

The commit that introduced the issue was 3136473.

My local workaround is just commenting the FMT_MSC_VERSION check in format.h:143 – the original problem from #519 doesn't affect modern Clang on Windows. (In fact it probably never affected real Clang/LLVM, only Microsoft's short-lived Clang/C2 experiment; but that's just a guess.) It probably needs to be a Clang/C2 check (instead of just an _MSC_VER check), but that experiment is long dead, so I suggest that maybe this workaround should just go away altogether...

vitaut referenced this issue Nov 30, 2022
Signed-off-by: Vladislav Shchapov <vladislav@shchapov.ru>
@vitaut vitaut closed this as completed Nov 30, 2022
@dodheim
Copy link

dodheim commented Dec 1, 2022

It compiles now, yes, but it's still avoiding use of __builtin_clz for Clang on Windows – why? That #if guard was inserted 5 years ago as a workaround for a now-dead piece of tech that Microsoft itself stopped supporting around the Clang 11.x timeframe...

@vitaut
Copy link
Contributor

vitaut commented Dec 1, 2022

@dodheim. a PR to remove the workaround is welcome.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants