Merged to master.

Merged to master.

Merged to master.

Merged to master.

Merged to master.

Merged to master.

Merged to master.

Thanks for report. I reproduced this by building i386 with optimizations disabled "-O0" (gcc 10). With normal optimization level such as "-O2", the issue does not appear.

Breakage appears to happen in configure.ac. When building with clang without LTO following check gives "no":

Yes, clang + LTO is broken. Maybe there is issue in clang bug tracker for this already?

Maybe this patch helps:

Thanks for you report.

Yes, bug is also in 1.8 branch.

Reimplemented 8 block parallel in "vertical" orientation.

With little extra effort, stitched implementation turned out ok after all.

Applied to s390x optimizations feature branch:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=7532e27cacb74c92fd561524a0897163b0fcd7f4

Applied to s390x optimizations feature branch:
SHA256: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=0b555c3cc7c2b80ec2628685946a6139a1996911
SHA512: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=45f0ec0c4e3b08627cbf7e65f5f110c321710d01

Applied to s390x optimizations feature branch:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=88570515b4ca92a44c4e40c31f877c11cc00ab68

Applied to s390x optimizations feature branch:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=5aeb091f911398217b2e9facb9bdeb05c63d7844

Applied to s390x optimizations feature branch:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=9219d9d1b60c01a4c7dbde05ee6b5b52e0d7d072

Implemented stitched ChaCha20-Poly1305 (vector ChaCha20 & ALU Poly1305). Unfortunately performance is less than OpenSSL (vector ChaCha20 & vector Poly1305). Instruction latencies make Poly1305 slower than combined OpenSSL ChaCha20+Poly1305, thus it is not possible to reach same performance with stitching. Vector Poly1305 implementation is therefore needed.

Currently have 8 block parallel implementation done. Need to check if 6 block parallel approach is better (as used in OpenSSL - benefit being less register pressure and less moving of data between registers and stack).

Thanks for reporting this. You are correct, those HWCAP2_SHA1 and HWCAP2_SHA2 defines are wrong.

AArch64 clang support was added to 'master' on 2018-03-28. One would need to backport commits 8ee38806245ca8452051b1a245f44082323f37f6...9b58e4a03ba3aeff7bae3f40da706977870c9649 to 1.8 branch.

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:

So, things I see are needed to be done for inclusion of this patch are:

1. GNU C coding style fixes.
2. 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:

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?

Just one question at the moment.