Compile bug: Parameter type truncation warning under Clang at `(uint32_t)abs(o.val_i64)`

[kaetemi]

Git commit

4d19698

Operating systems

Linux

GGML backends

CUDA

Problem description & steps to reproduce

Build warning under Clang

First Bad Commit

No response

Compile command

mkdir build_cuda
cd build_cuda
CC=clang CXX=clang++ cmake -G Ninja -DGGML_CUDA=ON -DLLAMA_CURL=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS="-O2" -DCMAKE_CXX_FLAGS="-O2" ..
ninja llama-server

Relevant log output

/home/kaetemi/llama.cpp/src/llama-quant.cpp:656:66: warning: absolute value function 'abs' given an argument of type 'const int64_t' (aka 'const long') but has parameter of type 'int' which may cause truncation of value [-Wabsolute-value]
  656 |                 gguf_set_val_u32(ctx_out.get(), o.key, (uint32_t)abs(o.val_i64));
      |                                                                  ^
/home/kaetemi/llama.cpp/src/llama-quant.cpp:656:66: note: use function 'std::abs' instead
  656 |                 gguf_set_val_u32(ctx_out.get(), o.key, (uint32_t)abs(o.val_i64));
      |                                                                  ^~~
      |                                                                  std::abs
1 warning generated.

[CISC]

You probably have a really old Clang installed, 64bit abs overload has been supported since C++11: https://cplusplus.com/reference/cstdlib/abs/

[kaetemi]

The overload is only standardized to exist under the std:: namespace, afaik. I'll double check the version, but it shouldn't be that old.

…

On Mon, Aug 18, 2025, at 01:18, Sigbjørn Skjæret wrote: *CISC* left a comment (ggml-org/llama.cpp#15374) <#15374 (comment)> You probably have a really old Clang installed, 64bit `abs` overload has been supported since C++11: https://cplusplus.com/reference/cstdlib/abs/ — Reply to this email directly, view it on GitHub <#15374 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMB77KLLQAHOGFWVWPWQAT3OC2PZAVCNFSM6AAAAACEC54QYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCOJUGUZDGNJYGY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[CISC]

The overload is only standardized to exist under the std:: namespace, afaik.

Nope, see link, it's under cstdlib.

[kaetemi]

Nope, see link, it's under cstdlib.

The standard under C++ only guarantees these functions from cstdlib to exist under the std:: namespace.

The standard also reserves the same function names in the global namespace but they are not required to actually be declared in the global namespace, as those refer to the C library standard, and are imported from stdlib.h, not the C++ standard, and do not necessarily include the overloaded versions under C++.

https://cplusplus.github.io/LWG/issue2380

[CISC]

Yet, no warnings with recentish Clang.

Clang 20.x:
https://github.com/ggml-org/llama.cpp/actions/runs/17032305986/job/48277360589#step:9:180

AppleClang 15.x:
https://github.com/ggml-org/llama.cpp/actions/runs/17032305979/job/48277360354#step:5:1750

[kaetemi]

root@---:~$ clang --version
Ubuntu clang version 14.0.0-1ubuntu1.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
root@---:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"

That's March 2022 and August 2024 respectively, not particularly old, and regardless, it does not make sense to me to prefer an implementation defined abs over the C++ standard std::abs form.

[kaetemi]

Duplicate/related issue #15044
Duplicate/related issue #15254
Related pull request #14209 seems incorrect

[CISC]

It's not about preference, it's just that the only PR about it so far is incorrect as you saw. :)

[kaetemi]

root@---:~$ nano t.cpp
root@---:~$ clang++ t.cpp -o t
ldd ./t | egrep 'libstdc\+\+|libc\+\+'
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f477c0d8000)
root@---:~$ strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX_ | tail -n 10
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_3.4.30
GLIBCXX_DEBUG_MESSAGE_LENGTH

Perhaps more relevant to check which version of the standard library is available and being compiled against on this distro.

[CISC]

Perhaps more relevant to check which version of the standard library is available and being compiled against on this distro.

Yeah, this must be why it works just fine everywhere else.

[kaetemi]

This is on a freshly updated Ubuntu 22.04 LTS container.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.