Valgrind error in rustsecp256k1_v0_4_0_ecdh/rustsecp256k1_v0_4_0_ge_neg on ppcel64

[TheBlueMatt]

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.

==525==    at 0x487F4D4: memcpy (vg_replace_strmem.c:1034)
==525==    by 0x514D023: rustsecp256k1_v0_4_0_ge_neg (group_impl.h:84)
==525==    by 0x5151FBF: rustsecp256k1_v0_4_0_ecmult_const (ecmult_const_impl.h:242)
==525==    by 0x515D00F: rustsecp256k1_v0_4_0_ecdh (main_impl.h:53)
==525==    by 0x5091ECF: secp256k1::ecdh::SharedSecret::new (ecdh.rs:108)
==525==    by 0x5096C37: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::outbound_noise_act (peer_channel_encryptor.rs:192)
==525==    by 0x5041B9F: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::get_act_one (peer_channel_encryptor.rs:248)
==525==    by 0x4E9F69F: lightning::ln::peer_handler::PeerManager<Descriptor,CM,RM,L>::new_outbound_connection (peer_handler.rs:464)
==525==    by 0x4FCFD3B: PeerManager_new_outbound_connection (peer_handler.rs:751)
==525==    by 0x114E83: PeersConnection::PeersConnection(LDK::ChannelManager&, LDK::ChannelManager&, LDK::PeerManager&, LDK::PeerManager&) (demo.cpp:261)
==525==    by 0x10DDAF: main (demo.cpp:406)
==525== 
==525== Source and destination overlap in memcpy(0x1ffeffc808, 0x1ffeffc808, 88)
==525==    at 0x487F4D4: memcpy (vg_replace_strmem.c:1034)
==525==    by 0x514D023: rustsecp256k1_v0_4_0_ge_neg (group_impl.h:84)
==525==    by 0x5152007: rustsecp256k1_v0_4_0_ecmult_const (ecmult_const_impl.h:247)
==525==    by 0x515D00F: rustsecp256k1_v0_4_0_ecdh (main_impl.h:53)
==525==    by 0x5091ECF: secp256k1::ecdh::SharedSecret::new (ecdh.rs:108)
==525==    by 0x5096C37: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::outbound_noise_act (peer_channel_encryptor.rs:192)
==525==    by 0x5041B9F: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::get_act_one (peer_channel_encryptor.rs:248)
==525==    by 0x4E9F69F: lightning::ln::peer_handler::PeerManager<Descriptor,CM,RM,L>::new_outbound_connection (peer_handler.rs:464)
==525==    by 0x4FCFD3B: PeerManager_new_outbound_connection (peer_handler.rs:751)
==525==    by 0x114E83: PeersConnection::PeersConnection(LDK::ChannelManager&, LDK::ChannelManager&, LDK::PeerManager&, LDK::PeerManager&) (demo.cpp:261)
==525==    by 0x10DDAF: main (demo.cpp:406)
==525== 
==525== Source and destination overlap in memcpy(0x1ffeffc808, 0x1ffeffc808, 88)
==525==    at 0x487F4D4: memcpy (vg_replace_strmem.c:1034)
==525==    by 0x514F84F: rustsecp256k1_v0_4_0_ge_mul_lambda (group_impl.h:654)
==525==    by 0x515201B: rustsecp256k1_v0_4_0_ecmult_const (ecmult_const_impl.h:248)
==525==    by 0x515D00F: rustsecp256k1_v0_4_0_ecdh (main_impl.h:53)
==525==    by 0x5091ECF: secp256k1::ecdh::SharedSecret::new (ecdh.rs:108)
==525==    by 0x5096C37: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::outbound_noise_act (peer_channel_encryptor.rs:192)
==525==    by 0x5041B9F: lightning::ln::peer_channel_encryptor::PeerChannelEncryptor::get_act_one (peer_channel_encryptor.rs:248)
==525==    by 0x4E9F69F: lightning::ln::peer_handler::PeerManager<Descriptor,CM,RM,L>::new_outbound_connection (peer_handler.rs:464)
==525==    by 0x4FCFD3B: PeerManager_new_outbound_connection (peer_handler.rs:751)
==525==    by 0x114E83: PeersConnection::PeersConnection(LDK::ChannelManager&, LDK::ChannelManager&, LDK::PeerManager&, LDK::PeerManager&) (demo.cpp:261)
==525==    by 0x10DDAF: main (demo.cpp:406)

[real-or-random]

That's a duplicate of #776 . But yes, we should get this fixed...