| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
The code handles both aligned and unaligned cases
|
|
|
|
|
| |
Commit afbd3e60f68f 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 afbd3e60f68f and e054d36dc88d00. 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 e054d36dc88d.
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.
|
| |
|
|
|
|
| |
Currently the CRYPTOPP_BOOL_XXX macros set the macro value to 0 or 1. If we remove setting the 0 value (the #else part of the expression), then the self tests speed up by about 0.3 seconds. I can't explain it, but I have observed it repeatedly.
This check-in prepares for the removal in Upstream master
|
| |
|
|
|
|
| |
We have made a fair number of changes, and we don't want WD to receive credit for issues he was not part of
|
| |
|
|
|
|
| |
trap.h and CRYPTOPP_ASSERT has existed for over a year in Master. We deferred on the cut-over waiting for a minor version bump (5.7). We have to use it now due to CVE-2016-7420
|
|
|
|
| |
(Issue 255)
|
| |
|
|
|
|
| |
language fodder
|
| |
|
| |
|
|
|
|
| |
(Coverity rollup)
|
| |
|
| |
|
| |
|
|
|
|
| |
default since integrated-as is default behavior and the bug is active). GNU_ATT_SYNTAX → GNU_AS_ATT_SYNTAX and GNUINTEL_SYNTAX → GNU_AS_INTEL_SYNTAX
|
|
|
|
| |
Bug 18916 (https://llvm.org/bugs/show_bug.cgi?id=18916)
|
| |
|
|
|
|
| |
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619856
|
| |
|
|
|
|
|
| |
fix minor documentation issues
fix compile w/o GAS 2.19 or later
|
| |
|
| |
|
|
|
|
|
|
| |
- added AuthenticatedSymmetricCipher interface class and Filter wrappers
- added CCM, GCM (with SSE2 assembly), CMAC, and SEED
- improved AES speed on x86 and x64
- removed WORD64_AVAILABLE; compiler 64-bit int support is now required
|
| |
|
| |
|
| |
|
|
|
| |
- improve stack unwindability on x64 for GCC by not modifying RBP/RSP registers in inline assembly
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|