Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Decoding doesn't work when compiled with mingw64 #269

Closed
xzn opened this issue May 13, 2023 · 8 comments
Closed

Decoding doesn't work when compiled with mingw64 #269

xzn opened this issue May 13, 2023 · 8 comments
Assignees
Labels

Comments

@xzn
Copy link

xzn commented May 13, 2023

As titled, decoding is broken when compiled with g++ from mingw64, always complaining about invalid encoded data.

Maybe a compiler bug? Not sure what in the myriad of templates triggers it (or something else entirely..)

(clang++ or g++ with ucrt doesn't work either..)

@vbaderks
Copy link
Contributor

Thanks for the report. I Will try to reproduce it. On which version of Charls and mingw64 do you see the problem?

@xzn
Copy link
Author

xzn commented May 13, 2023

g++

$ g++ --version
g++.exe (Rev5, Built by MSYS2 project) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

clang

$ clang++ --version
clang version 16.0.2
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: D:/Compilers/msys64/clang64/bin

To compile I used cmake -G "Unix Makefiles" in mingw64 prompt
or CC=clang CXX=clang++ cmake -G "Unix Makefiles" in clang64 prompt
Then make charlstest
Then make test
Which fails

My own attempts at using the decoding interface don't work either.

(Also just tried WinLibs MinGW-w64 distribution which has the same problem so it's likely not a problem with my mingw64 installation)

Forgot to mention the charls version:
I tried both the current main branch and the 2.x branch, both exhibit the same problem.

@xzn
Copy link
Author

xzn commented May 13, 2023

I've bisected the problem to commit 0b3ac70

Hope it helps.

@xzn
Copy link
Author

xzn commented May 13, 2023

eh why does g++ generate 32-bit bsr and mask??

image

This is so weird.

Edit:
nvm I just remembered that on windows long is 32-bit even on 64-bit platform, need __builtin_clzll i guess.

@xzn
Copy link
Author

xzn commented May 13, 2023

I guess this workaround will do for now ...

template<class T>
auto countl_zero(T value) noexcept -> std::enable_if_t<is_uint_v<64, T>, int>
{
    return countl_zero(static_cast<uint32_t>(value >> 32));
}

Maybe change the name of the function to countl32_zero if going with this.

Edit: this works:

diff --git a/src/util.h b/src/util.h
index ffae177..215ebd4 100644
--- a/src/util.h
+++ b/src/util.h
@@ -445,7 +445,11 @@ auto countl_zero(T value) noexcept -> std::enable_if_t<is_uint_v<64, T>, int>
     if (value == 0)
         return 64;

+#ifdef _WIN32
+    return __builtin_clzll(value);
+#else
     return __builtin_clzl(value);
+#endif
 }

 /// <summary>

@vbaderks vbaderks added the bug label May 13, 2023
@vbaderks
Copy link
Contributor

commit 36807a0 resolves this problem in the main branch.
Note: using __builtin_clzll is always possible and is preferable then an extra #ifdef/#else/#endif construction.

Intend is to apply this fix to the v2.4.x branch and research if it is possible to add msys2 to the CI pipeline.

@vbaderks vbaderks self-assigned this May 14, 2023
@vbaderks
Copy link
Contributor

A fix for this defect has been applied to the release/2.x branch and release v2.4.2 is available.

@vbaderks
Copy link
Contributor

The CI pipeline has been extended with MSYS2 to ensure that future releases are automatically verified.
Again, thanks for the report and the fix.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants