Valgrind complains on ppcel64 that the *r = *a in ge_neg when called by ecmult_const (as secp256k1_ge_neg(&correction, &correction); is turned into a memcpy with withe same source/dest. This sounds like a bug in gcc (Debian 10.2.1-6 ie latest from testing/bullseye), but dunno if there’s something worth doing to work around this or if it should be moved upstream to gcc. Valgrind output below, sorry for the mangled symbol names, rust-secp256k1 does that to avoid multiple versions conflicting.
0==525== at 0x487F4D4: memcpy (vg_replace_strmem.c:1034)
1==525== by 0x514D023: rustsecp256k1_v0_4_0_ge_neg (group_impl.h:84)
2==525== by 0x5151FBF: rustsecp256k1_v0_4_0_ecmult_const (ecmult_const_impl.h:242)
3==525== by 0x515D00F: rustsecp256k1_v0_4_0_ecdh (main_impl.h:53)
4==525== by 0x5091ECF: secp256k1::ecdh::SharedSecret::new (ecdh.rs:108)
5==525== by 0x5096C37: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::outbound_noise_act (peer_channel_encryptor.rs:192)
6==525== by 0x5041B9F: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::get_act_one (peer_channel_encryptor.rs:248)
7==525== by 0x4E9F69F: lightning::ln::peer_handler::PeerManager<Descriptor,CM,RM,L>::new_outbound_connection (peer_handler.rs:464)
8==525== by 0x4FCFD3B: PeerManager_new_outbound_connection (peer_handler.rs:751)
9==525== by 0x114E83: PeersConnection::PeersConnection(LDK::ChannelManager&, LDK::ChannelManager&, LDK::PeerManager&, LDK::PeerManager&) (demo.cpp:261)
10==525== by 0x10DDAF: main (demo.cpp:406)
11==525==
12==525== Source and destination overlap in memcpy(0x1ffeffc808, 0x1ffeffc808, 88)
13==525== at 0x487F4D4: memcpy (vg_replace_strmem.c:1034)
14==525== by 0x514D023: rustsecp256k1_v0_4_0_ge_neg (group_impl.h:84)
15==525== by 0x5152007: rustsecp256k1_v0_4_0_ecmult_const (ecmult_const_impl.h:247)
16==525== by 0x515D00F: rustsecp256k1_v0_4_0_ecdh (main_impl.h:53)
17==525== by 0x5091ECF: secp256k1::ecdh::SharedSecret::new (ecdh.rs:108)
18==525== by 0x5096C37: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::outbound_noise_act (peer_channel_encryptor.rs:192)
19==525== by 0x5041B9F: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::get_act_one (peer_channel_encryptor.rs:248)
20==525== by 0x4E9F69F: lightning::ln::peer_handler::PeerManager<Descriptor,CM,RM,L>::new_outbound_connection (peer_handler.rs:464)
21==525== by 0x4FCFD3B: PeerManager_new_outbound_connection (peer_handler.rs:751)
22==525== by 0x114E83: PeersConnection::PeersConnection(LDK::ChannelManager&, LDK::ChannelManager&, LDK::PeerManager&, LDK::PeerManager&) (demo.cpp:261)
23==525== by 0x10DDAF: main (demo.cpp:406)
24==525==
25==525== Source and destination overlap in memcpy(0x1ffeffc808, 0x1ffeffc808, 88)
26==525== at 0x487F4D4: memcpy (vg_replace_strmem.c:1034)
27==525== by 0x514F84F: rustsecp256k1_v0_4_0_ge_mul_lambda (group_impl.h:654)
28==525== by 0x515201B: rustsecp256k1_v0_4_0_ecmult_const (ecmult_const_impl.h:248)
29==525== by 0x515D00F: rustsecp256k1_v0_4_0_ecdh (main_impl.h:53)
30==525== by 0x5091ECF: secp256k1::ecdh::SharedSecret::new (ecdh.rs:108)
31==525== by 0x5096C37: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::outbound_noise_act (peer_channel_encryptor.rs:192)
32==525== by 0x5041B9F: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::get_act_one (peer_channel_encryptor.rs:248)
33==525== by 0x4E9F69F: lightning::ln::peer_handler::PeerManager<Descriptor,CM,RM,L>::new_outbound_connection (peer_handler.rs:464)
34==525== by 0x4FCFD3B: PeerManager_new_outbound_connection (peer_handler.rs:751)
35==525== by 0x114E83: PeersConnection::PeersConnection(LDK::ChannelManager&, LDK::ChannelManager&, LDK::PeerManager&, LDK::PeerManager&) (demo.cpp:261)
36==525== by 0x10DDAF: main (demo.cpp:406)
