If we provide too large a value for the alignment attribute APInt::getZExtValue() will assert. This PR adds a active bits check and folds it into the MaximumAlignment check.
This fixes: https://github.com/llvm/llvm-project/issues/50534
Differential D152335
[Clang] Add check to Sema::AddAlignedAttr to verify active bits is not out of range shafik on Jun 6 2023, 8:04 PM. Authored by
Details If we provide too large a value for the alignment attribute APInt::getZExtValue() will assert. This PR adds a active bits check and folds it into the MaximumAlignment check. This fixes: https://github.com/llvm/llvm-project/issues/50534
Diff Detail Event Timeline
Comment Actions Needs a release note. Also, the changing of order is POSSIBLY a change in behavior (in that we're now diagnosing 'out of range' before 'power of 2'), but I don't think we care. Comment Actions LGTM with a release note. I don't consider that a behavioral change to be worried about. Telling the user "this value is too big" before telling them "it's not a power of two" seems equivalent or perhaps slightly better than "this is not a power of two" and then "oh, and it's too big." Comment Actions Well, its telling them "this value is too big" instead of "its not a power of two" rather than the other way around. But yeah, i don't think I care? I'm a little frightened there is no test that fails because of this, but not surprised. |
What is the purpose of using 'ActiveBits' here? Why is this not a sub-set of the operator > from below? That is, 'ActiveBits' allows for 0xFF when the 'MaxValue' is 0x80 (top bit set), but the operator > would have caught that anyway, right?
Also, how does 'ActiveBits' work with negative numbers?