[libc-commits] [PATCH] D148759: [libc] Support constexpr uint initialization
Mikhail Ramalho via Phabricator via libc-commits
libc-commits at lists.llvm.org
Thu Apr 20 05:01:02 PDT 2023
mikhail.ramalho added a comment.
Thanks, it fixed the problem with `sub_with_borrow` and `add_with_carry` in riscv32 for me!
The extra operators also helped with the compilation and only one extra change was required to get libc built for riscv32:
diff --git a/libc/src/__support/FPUtil/NearestIntegerOperations.h b/libc/src/__support/FPUtil/NearestIntegerOperations.h
index 06aa9484c3f7..b9332528f60c 100644
--- a/libc/src/__support/FPUtil/NearestIntegerOperations.h
+++ b/libc/src/__support/FPUtil/NearestIntegerOperations.h
@@ -133,7 +133,7 @@ LIBC_INLINE T round(T x) {
}
uint32_t trim_size = MantissaWidth<T>::VALUE - exponent;
- bool half_bit_set = bits.get_mantissa() & (UIntType(1) << (trim_size - 1));
+ bool half_bit_set = bool(bits.get_mantissa() & (UIntType(1) << (trim_size - 1)));
bits.set_mantissa((bits.get_mantissa() >> trim_size) << trim_size);
T trunc_value = T(bits);
If the operators are accepted in this patch, do you mind adding this one change as well?
================
Comment at: libc/src/__support/UInt.h:97
+ constexpr explicit operator bool() const { return (*this) == 1; }
+
----------------
sivachandra wrote:
> Is this required for the functionality of this change? Also, wouldn't a more correct check be `*this != 0`?
I did something similar to get compilation working in riscv32, but as:
```
constexpr explicit operator bool() const { return !is_zero(); }
```
I think Operator== will construct a UInt(1), while is_zero doesn't
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D148759/new/
https://reviews.llvm.org/D148759
More information about the libc-commits
mailing list