This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 39510 Build 39530: arc lint + arc unit
Event Timeline
Please rename commit to [Alignment][NFC] Move and type functions from MathExtra to Alignment
llvm/unittests/Support/AlignmentTest.cpp | ||
---|---|---|
212 | Add comment: // A value of any integral or enumeration type can be converted to a pointer type. I had to check to verify that this was legal. |
llvm/include/llvm/Support/Alignment.h | ||
---|---|---|
176 | Because Alignment.value() is a uint64_t, this won't catch overflows when addresses are 32 bits. This breaks the AlignmentDeathTest.AlignAddr test on 32-bit Windows, for example. And also here: http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/10957 Hopefully r375090 fixes this, but maybe it would be better for Alignment::value() not to be 64-bit for example. |
Because Alignment.value() is a uint64_t, this won't catch overflows when addresses are 32 bits.
This breaks the AlignmentDeathTest.AlignAddr test on 32-bit Windows, for example. And also here: http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/10957
Hopefully r375090 fixes this, but maybe it would be better for Alignment::value() not to be 64-bit for example.