You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just came across 1f63577 which changes the type of array/vector lengths from int64 to uint64. This broke some code I have that multiplies by the bitsize of the element type because now they have different types.
I don't mind too much which type is used, but it seems to me that whatever logic is used to choose signed vs unsigned would apply equally well to both, and the consistency breakage is a downside
I cross-checked against the official LLVM implementation, and you are indeed correct. Bit size should be unsigned. So, lets make it uint64 to use the same type used in ArrayType and VectorType.
uint64_t NumBits = atoull(StartChar, CurPtr);
if (NumBits < IntegerType::MIN_INT_BITS ||
NumBits > IntegerType::MAX_INT_BITS) {
Error("bitwidth for integer type out of range!");
return lltok::Error;
}
enum {
MIN_INT_BITS = 1, ///< Minimum number of bits that can be specified
MAX_INT_BITS = (1<<24)-1 ///< Maximum number of bits that can be specified
///< Note that bit width is stored in the Type classes SubclassData field
///< which has 24 bits. This yields a maximum bit width of 16,777,215
///< bits.
};
Just came across 1f63577 which changes the type of array/vector lengths from
int64
touint64
. This broke some code I have that multiplies by the bitsize of the element type because now they have different types.I don't mind too much which type is used, but it seems to me that whatever logic is used to choose signed vs unsigned would apply equally well to both, and the consistency breakage is a downside
llvm/ir/types/types.go
Lines 208 to 214 in acfb969
llvm/ir/types/types.go
Lines 601 to 609 in acfb969
The text was updated successfully, but these errors were encountered: