Commit afbd3e60f6 effectively treated a symptom and not the underlying problem. The problem was linkers on 32-bit systems ignore CRYPTOPP_ALIGN_DAT(16) passed down by the compiler and align to 8-bytes or less. We have to use Wei's original code in some places. It is not a bad thing, but the bit fiddling is something we would like to contain a little more by depending more on language or platform features.
This commit keeps the original changes which improve partial specializations; but fixes 32-bit linker behavior by effectively reverting afbd3e60f6 and e054d36dc8. We also add more comments so the next person has understands why things are done they way they are.
These fixes were interesting in a morbid sort of way. I thought the FixedSizeAllocatorWithCleanup specializations faithfully reproduced semantics but I was wrong on Win32 and Sparc. Also see Commit e054d36dc8.
It seems there was another requirement or dependency that we missed, but it was not readily apparent. If I am parsing results correctly (which I may not be), it appears the bit twiddling using 8 byte alignment had more influence on alignment than I originally thought based on use of CRYPTOPP_BOOL_ALIGN16 and T_Align16. Or maybe the alignment attributes specified by CRYPTOPP_ALIGN_DATA are not being honored like they should for stack allocations.
This check-in avoids some uses of x86 movdqa (aligned) in favor of movdqu (unaligned). The uses were concentrated on memory operands which were 8-byte aligned instead of 16-byte aligned. It is not clear to me how the specializations lost 8-bytes of alignment. The check-in also enlists CRYPTOPP_ASSERT to tell us when there's a problem so we don't need to go hunting for bugs.
This allocator still has some demons buried inside due to the bit fiddling. This commit should isolate the demons to aligned stack allocations when an alignment facility from the platform or OS is not available. That is, we use CRYPTOPP_ALIGN_DATA when we can because it is most reliable.
We can tell when things have gone sideways using Debug builds. The CRYPTOPP_ASSERT(m_allocated) will fire on destruction because the flag gets overwritten.
This commit also favors init priorities over C++ dynamic initialization. After the std::call_once problems on Sparc and PowerPC I'm worried about problems with Dynamic Initialization and Destruction with Concurrency.
We also do away with supressing warnings and use CRYPTOPP_UNUSED instead.
I was not able to duplicate it under GCC. That includes the GCC's supplied with Debian 8 and Ubuntu 14. It looks like the problem was with Asan insread of the library
It looks like GCC is rejecting the -pthread option but it is advertising Pthread support by defining 39 related macros. I'm not sure what to make of it, but we can't use -pthread because it breaks the compile.
Jeffrey Walton