[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