- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 3 2020
AArch64 clang support was added to 'master' on 2018-03-28. One would need to backport commits 8ee38806245ca8452051b1a245f44082323f37f6...9b58e4a03ba3aeff7bae3f40da706977870c9649 to 1.8 branch.
Nov 30 2020
Another issue that comes in to mind is that current ARM/ARM64 HW feature detection most likely wont work on MacOS. Thus HW accelerated AES&SHA&GHASH implementation wont be used.
HAVE_COMPATIBLE_GCC_AMD64_PLATFORM_AS is never defined on ARM64 as it depends on "$mpi_cpu_arch" == "x86". Instead I think new check for GCC assembly ELF directives would be needed in configure.ac, similar to HAVE_GCC_ASM_CFI_DIRECTIVES check. Following check should work, but I have not yet tested it:
Oct 1 2020
Sep 30 2020
Aug 29 2020
So, things I see are needed to be done for inclusion of this patch are:
- GNU C coding style fixes.
- Adding comment about that this implementation is based on GHASH implementation by Andy Polyakov with original license. This needs to be checked with @werner , but I think following would be sufficient:
Aug 3 2020
Jun 29 2020
When I took side-by-side comparison of cryptogams version to this patch, what I find is that they are strikingly similar. Operation/instruction ordering matches closely to parts of ghashp8-ppc.pl. In many parts variable/register names are the same also.
Ok. This was just something that I noticed while going through configure.ac. Should I make patch for this or do you want to?
Jun 20 2020
Just one question at the moment.
Jun 18 2020
Thanks for the new version. Unfortunately Minicloud seems to be down and therefore cannot test patch at the moment. I'll take look when I regain power64 access.
Jun 16 2020
Jun 8 2020
Jun 3 2020
Jun 1 2020
Apr 27 2020
Apr 19 2020
Apr 16 2020
Generally nice looking patch and great improvement for performance.
Apr 14 2020
Apr 6 2020
In T4906#133954, @JW wrote:I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?
Apr 4 2020
Attached patch should solve the issue for gcc 7.5 and clang 8.
Apr 2 2020
Feb 3 2020
Feb 2 2020
Feb 1 2020
Thanks for reporting this this. Your patch is correct.
Jan 22 2020
Patch have been applied to master, https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=79ed620ec46adbb08f5cea6a4865a95a436e4109
Jan 19 2020
Thanks for bug fix. I've prepared patch and send it to mailing list https://lists.gnupg.org/pipermail/gcrypt-devel/2020-January/004885.html. Let me know if Reported-by is ok/enough. I would have liked to put you as author of commit, but this Differential interface of quite horrible and does not give all the needed information (mainly "name <email>" format for git).
Dec 25 2019
Dec 9 2019
I've been wondering this also. I can start working on this.
Nov 28 2019
Nov 21 2019
Nov 8 2019
Please note that C-based intrinsic implementation is the way to go now as that is the path chosen for PowerPC implementations in libgcrypt.
Nov 5 2019
Oct 16 2019
Sep 26 2019
Sep 16 2019
Sep 15 2019
Sep 6 2019
Poly1305 addition helper for ppc64 posted on mailing list: https://lists.gnupg.org/pipermail/gcrypt-devel/2019-September/004804.html
Sep 3 2019
PowerPC SHA-256 and SHA-512 implementations with little bit more tuning committed. Most notably, SHA-512 on POWER8 now gives similar performance to OpenSSL: