That would destroy the timing information, but no one seems to be paying attention to that anyway. I recommend just picking smaller buffer sizes. But 11 is too small. Small enough to pass on your embedded platform, but not in the range of a typical alignof(max_align_t).
Howard On Dec 16, 2015, at 8:50 AM, Craig, Ben <ben.cr...@codeaurora.org> wrote: > > As an alternative, would it be acceptable to heap allocate these objects, > using the original padding numbers? > > On 12/15/2015 5:11 PM, Howard Hinnant wrote: >> On Dec 15, 2015, at 5:30 PM, Jonathan Roelofs <jonat...@codesourcery.com> >> wrote: >>> >>> Could these large padding things be related to the fact that the test is >>> used as a performance check for the implementation? That being said, I have >>> no idea who is paying attention to the numbers that come out of this test >>> (if anyone even is?). Maybe @howard.hinnant knows something about it? >> It’s been a few years since I wrote this code, but my best recollection is >> that the large buffers indicate my concern of getting the correct answer >> accidentally as the dynamic_cast code will add/subtract offsets to pointers. >> The implementation is wicked hard to get right, and so the tests are extra >> paranoid. >> >> As I wrote this I only had to worry about OS X / iOS. If you need to reduce >> these numbers for other platforms, I think that would be fine. However I >> would not reduce them to double digits. I would keep them as large as you >> can reasonably get away with. >> >> There may have also been effort to make sure that the numbers involved were >> not even close to multiples of one another, or add up to each other, etc, I >> don’t remember for sure. The main concern is that the offset arithmetic >> implemented under __dynamic_cast does not accidentally get the right answer. >> And I suspect alignment is also factored in to the offset computation (I >> don’t recall for sure), and so one can not depend entirely on small primes >> (which may be rounded to alignment). >> >> Handy link: >> >> http://mentorembedded.github.io/cxx-abi/abi.html#dynamic_cast-algorithm >> >> Normally I don’t write a lot of comments in code. Code should be self >> explanatory. The sheer volume of comments in private_typeinfo.cpp should >> serve as a signal that this code is very tricky. So I recommend keeping the >> tests as paranoid as possible. >> >> Howard >> > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux > Foundation Collaborative Project > _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
