Details
- Reviewers
EricWF
Diff Detail
- Repository
- rL LLVM
Event Timeline
See https://reviews.llvm.org/D36446 and https://reviews.llvm.org/D36447 for the fixes themselves.
test/dynamic_cast.pass.cpp | ||
---|---|---|
24 | I wonder whether these types could reasonably be char[11], char[23], char[35], char[47], char[59], char[71] etc., instead of being many tens of kilobytes. They don't *have* to be big in order for the unpatched library to fail the test, right? In fact the unpatched library ought to fail the test even when they're all char[1]? |
@Quuxplusone Yes, the tests fail regardless of whether the padding fields exist or how large they are. I copied them from the other libcxxabi dynamic_cast* tests. I'm not really sure what they do. Considering their sizes, I'm guessing the intent was something like, "ensure that every combination of padding fields (plus internal vptrs / alignment) yields a unique sum". Adding padding fields also seems to make pointers of different types have different values. (Maybe the "nearly empty class" stuff in the Itanium C++ ABI document is relevant.)
Maybe the padding could be smaller.
At one point, the large padding caused a stack overflow on embedded targets -- it was fixed here: https://github.com/llvm-mirror/libcxxabi/commit/eca353d4849b2b1f7bca76edb40b3534433a5a26.
test/dynamic_cast.pass.cpp | ||
---|---|---|
24 |
Hm. Well, if it's just copied from elsewhere, then sure, whatever. :) I withdraw the comment. |
Can these tests be checked in with their respective fixes, so both the test and the fix can be committed atomically?
I wonder whether these types could reasonably be char[11], char[23], char[35], char[47], char[59], char[71] etc., instead of being many tens of kilobytes. They don't *have* to be big in order for the unpatched library to fail the test, right? In fact the unpatched library ought to fail the test even when they're all char[1]?