Forcefully disable RVV intrinsics usage in llama.cpp/libggml.
The code assumes that if __riscv_v_intrinsic is defined the various RVV
intrinsics are available and usable.
With clang the intrinsics may be available even though actual usage of
said intrinsics has to be allowed with clang -march=... or function
annotations.
Also the code assumes that if it can use said intrinsics at compile
time then they ought to be used at runtime. This is false on
OpenBSD which doesn't require the cpu to support the V extension.
Example error at compile time:
.../firefox-154.0/third_party/llama.cpp/ggml/src/ggml-cpu/vec.cpp:407:22: error: RISC-V type 'vfloat32m2_t' (aka '__rvv_float32m2_t') requires the 'zve32f' extension
407 vfloat32m2_t vx = __riscv_vle32_v_f32m2(&x[i], vl);
With & ok landry@ (maintainer)
fish/v3: fix build with libcxx22
libcxx22 uses [[__fallthrough__]] in a couple of headers, so redefining
__fallthrough__ to __attribute__((fallthrough)) yields a syntax error:
/usr/include/c++/v1/__functional/hash.h:70:24: error: expected expression
70 | [[__fallthrough__]];
| ^
Just don't do that...
rsa_eay: Replace handrolled BN_bn2binpad with the real thing
Just a tiny little bit of lipstick on this entelodont. This is simpler
and does not change behavior as BN_bn2binpad() returns -1 on failure and
num on success.
jsing points out that BN_bn2binpad() is constant time.
ok jsing kenjiro
PS: henning, you owe me a significant amount of quality beverages for
making me look at this particular tire fire (and corresponding XS files).
libcrypto: harden cms_kek_cipher() a bit
When AES key unwrap with padding is in use, the EVP interface breaks its
contract and writes more than the outlen it initially reports to the output
buffer. This is an old, sneaky trap that the muppet set eons ago and many
victims walked right into it, including the muppet himself.
If inlen is larger than outlen, allocate inlen bytes to unwrap with padding
to avoid a buffer overwrite. This is a variant of OpenSSL's fix. Since we
do not support AES keywrap with padding no actual bufer overwrite occurs
here at the moment, but if we ever chose to do so (unlikely) this trap
would be avoided. There's plenty more traps that the next round of scas
will surely find in this absolute trashfire of CMS support code.
ok kenjiro
Do not try to configure 0.0.0.0 (INADDR_ANY) on an interface.
If we indicate a preference for IPv6-only (DHCP option 108), the
server does not offer an IP address (indicated by INADDR_ANY), so we
must first check if the server supported option 108 before checking if
we received an IPv4 offer.
Logic error pointed out and diff provided by acts1631 at proton.me,
thanks!
