Also applied to 1.10.

Applied and pushed.

Problem is that new assembly is using VSX registers vs14-vs31 which overlap with floating-point registers f14-f31. f14-f31 are ABI callee saved, so those need to be stored and restored.

Tested patch with small change so that HWF_PPC_ARCH_3_00 is used instead of HWF_PPC_ARCH_3_10. Building bench-slope with "-O3 -flto" makes bug in new implementation visible. Without new implementations bench-slope is ok (testing with QEMU):

$ tests/bench-slope --disable-hwf ppc-arch_3_00 cipher chacha20
Cipher:
 CHACHA20       |  nanosecs/byte   mebibytes/sec   cycles/byte
     STREAM enc |      2.35 ns/B     405.0 MiB/s         - c/B
     STREAM dec |      2.32 ns/B     410.7 MiB/s         - c/B
   POLY1305 enc |      2.46 ns/B     388.0 MiB/s         - c/B
   POLY1305 dec |      2.34 ns/B     408.1 MiB/s         - c/B
  POLY1305 auth |     0.238 ns/B      4003 MiB/s         - c/B

-O2 problem with bench-slope seems strange. Does problem appear after this patch is applied?

This feature is implemented in different way, by T5099.

In T5975#158113, @werner wrote:

I can imagine thar there are use cases for this. Thus I see no problems for the first part.

The second part is imho not a good idea. Libgcrypt is a building block for all kind of software and there are for sure legitimate reasons to use rsa512 (MCUs, short living keys, etc). Thus I think that the decision on the key size should be done by the software using libgcrypt.

Pushed the change (master and 1.10).

To detect these kinds of bugs, possibly, we can use new GCC option: -ftrivial-auto-var-init=0xFEFEFEFE.
https://gcc.gnu.org/gcc-12/changes.html#uninitialized

The bug was there when it was initially written. It was in 2003, which introduced PC/SC in rG1bcf8ef9dea1: Cleanups, fixes and PC/SC support

I just wrote a blog article about this problem
https://ludovicrousseau.blogspot.com/2022/05/scardlistreaders-and-non-initialized.html

Thanks for opening a ticket.

Ok. Thank you for the clarification. I will drop the second part and keep only the FIPS change in the patch. Merge request already updated.

Thanks. Should be applied.

I can imagine thar there are use cases for this. Thus I see no problems for the first part.

Pushed the changes for http.c.

Last part is applied. Let me consider how to solve, for other parts.

I guess I don't understand what you mean by "native building". This build was with MinGW, which is as "native" as MinGW64 is.
The reason for the problem is (AFAIU) that MinGW64 went after Microsoft's change in stat due to the 32-bit vs 64-bit time and off_t values issue.s That change breaks backward compatibility in more than one way: programs compiled on some versions of Windows will not run on other versions. mingw.org's MinGW kept the original semantics and symbols, which is why _stat32 exists in the mingw.org's headers, but is not exposed by default.

Turned into a feature request because native building on Windows is not supported.

Thanks for you patches. Most of them applied cleanly despite that I delayed processing them for half a year.

Ok, I'll add.

Seen. @jukivili can you please add it to the AUTHORS file?

Ok, I have subscribed to the mailing list. I have resent the DCO.

DCO has not appeared on mailing-list. You can this from check list archives, https://lists.gnupg.org/pipermail/gcrypt-devel/2021-December/thread.html

Thanks Jussi, I did not receive the list moderator's email so I am not sure if the it has been posted on gcrypt-devel@gnupg.org. If not, I can resend the DCO. Thanks.

I did some finishing touches on coding style:

Hi Jussi,

Few comments on new patch:

Hi jukivili,

Hi jukivili,
I ran some basic tests and it did show the errors. I am in the process investigating what went wrong. In the meantime, i also included test result that I have used in my testing from bench-slope. In this test, I captured the message with 272 bytes buffer from the original libgcrypt repo and my optimized repo. Note that the bulk version of my code do 8x unrolling and the rest will do 16 bytes. So the first 2 128 bytes ran thru gcry_ppc_aes_gcm_encrypt and the rest of the 16 bytes thru gcm_ctr_encrypt (cipher-gcm.c).

Thanks jukivili for the review.

Thanks, however I didn't see your email on mailing-list. Maybe the email got stuck on the way.

I sent a copy to gcrypt-devel@gnupg.org. Hope this is the right process. Thanks.

Please read doc/HACKING carefully on the process of sending DCO the right way.

Hi Werner, Here is the DCO. Thanks.

FWIW: We need a DCO; see doc/HACKING.

Code for avoiding the COMMON section has been there, because of RISC OS.
I think that it will be easier to enable that for all (but not for RISC OS only).

Regarding your patch, I am personally not opposed to it, but apparently Debian’s policy says the library/module should be called scute while Gentoo’s policy says it should be called libscute… What should an upstream developer do?

Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.

The built file is called scute instead of libscute because it is considered to be a *module*, not a *library*. That’s apparently a Debian thing, see commit dc2211179ea7f63434d726eefbc425390c4c6427.

Fixed typos and applied to master. Thanks.

Latext 1.9.1 builds without any unreported workarounds. Done. Close.

Sure. Thanks for testing. The problem with new versions is that ppl don't like to test release candidates and thus we need do real releases and wait for the outfall. ;-)

Fixed by jukvilli’s patch.
__outer

That works, thanks. So does that become part of the next release?
__outer

The code has been reworked to also support the updated schema which also stores the fingerprints and a parsed down mail address. See gnupg/doc/ldap/ . These changes are in master and 2.2.26. Sorry for taking so long to fix that.

Thanks. I added the OIDs and the missing curves. To go into 1.9

Okay. Now since configure.ac is already touching CFLAGS, it seemed like a good place to add that additional option here. All this is guarded by a test for GCC, and since clang mimics that behaviour, it works for them as well.

Take care: gpg is also used on platforms with proprietary compilers which don't support -f options. Thus you need to limit this to gcc.

After some more checking: LLVM-11 introduced the same behaviour in that regard, but appearently not a pragma/attribute to override this: https://releases.llvm.org/11.0.0/tools/clang/docs/ReleaseNotes.html

Thus better add a

&& !defined(__clang__)

Sure that the FreeBSD compiler does not define it? I am pretty sure it does.

According to list of attributes in the clang 12 documention, there is no such attribute in clang. However, the clang-11 compiler (as seen in Debian) does not define __GNUC__, so the proposed patch does not affect the status when building with clang.

You may want to check that clang supports this attribute as well.

Thanks for the patch, applied!
You are correct the NEWS file states that this was added in 1.9.0

I checked the code and your patch looks right. I am going to apply it.

Committed.