All Major Linux Compilers miscomplie restrict

[TheBlueMatt]

It looks like your project uses the "restrict" keyword. Both GCC since version 5 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87609) and CLANG for some time (https://bugs.llvm.org/show_bug.cgi?id=39282) can miscompile restrict-tagged pointers especially when called in loops/inlining. Seems "restrict" shouldn't be used in modern C.

[jgarzik]

restrict is also used in the C library, glibc.

[TheBlueMatt]

What does that have to do with anything? Just cause one thing may be broken doesn't mean we should also risk our own stuff being broken.

[jgarzik]

What does that have to do with anything? Just cause one thing may be broken doesn't mean we should also risk our own stuff being broken.

Well,

• Anything using common functions is theoretically getting miscompiled, including pthread, stdlib, signal, stdio and string functions used by basically every project.
• Miscompilation is happening, regardless of any action or inaction here. It will continue to impact bitcoin through dependencies, regardless of action/inaction here.

It will take a long time to fix, so just remove restrict from secp256k1 and move on.

[TheBlueMatt]

Thanks for the random comment? Still has no relevance to this issue or the fix. If you're going to try to contribute to Bitcoin projects again, please try to be productive, don't add tangential things just for the sake of it. Further, note that there are no known miscompilation bugs in glibc, especially given the auto-inlining of many relevant functions this seems unlikely to go unnoticed. You may wish to read the original bug reports linked in the first comment.

[real-or-random]

This has been fixed in GCC 7, 8 ,9 (>=7.4.1, >= 8.3.1, >= 9.0) and clang 12.

Closing because I don't think we want to take further action at this stage. If you don't agree, please don't hesitate to tell us.