CompCert VS corn

A big problem is that proving that transformations preserve semantics is very hard. Formal methods has huge potential and I believe it will be a big part of the future, but it hasn't become mainstream yet. Probably a big reason why is that right now it's simply not practical: the things you can prove are much more limited than the things you can do, and it's a lot less work to just create a large testsuite.

Example: CompCert (https://compcert.org/), a formally-verified compiler AKA formally-verified sequence of semantics-preserving transformations from C code to Assembly. It's a great accomplishment, but few people are actually compiling their code with CompCert. Because GCC and LLVM are much faster[1], and have been used so widely that >99.9% of code is going to be compiled correctly, especially code which isn't doing anything extremely weird.

But as articles like this show, no matter how large a testsuite there may always be bugs, tests will never provide the kind of guarantees formal verification does.

[1] From CompCert, "Performance of the generated code is decent but not outstanding: on PowerPC, about 90% of the performance of GCC version 4 at optimization level 1"

Also a C compiler (https://compcert.org/). I did exaggerate bit in saying that anything non-trivial is "nearly impossible".

However, both CompCert and sel4 took a few years to develop, whereas it would only take months if not weeks to make versions of both which aren't formally verified but heavily tested.

From my experience, while many MCUs have settled for the big compilers (GCC and Clang), DSPs and some FPGAs (not Intel and Xilinx, those have lately settled for Clang and a combination of Clang and GCC respectively) use some pretty bespoke compilers (just running ./ --version is enough to verify this, if the compiler even offers that option). That's not necessarily bad, since many of them offer some really useful features, but error messages can be really cryptic in some cases. Also some industries require use of verified compilers, like CompCert[1], and in such cases GCC and Clang just don't cut it.

[1]: https://compcert.org/

CompCert sends its regards

But that's fine, because we can do even better with things like the CompCert C compiler, which is formally proven to produce correct asm output for ISO C 2011 source. It's designed for high-reliability, safety-critical applications; it's used for things like Airbus A380 avionics software, or control software for emergency generators at nuclear power plants. Software that's probably not overly sophisticated and doesn't need to be highly optimized, but does need to work ~100% correctly, ~100% of the time.

For context, CompCert is a formally verified compiler. My former advisor helped with a fuzzer called CSmith which found plenty of bugs in GCC and LLVM but not in CompCert.

Does anybody know how does this compare to https://compcert.org/ ?

This is a common property for proof-oriented languages. Coq shares this property for instance, and you can write an optimizing C compiler in Coq: https://github.com/AbsInt/CompCert .

> Or there are these high level systems for proving deep theorems. Is anyone trying to fill the gap?

There's ongoing work on computable real numbers for instance the CoRN library[1], so hope is on the horizon, for instance, a recent update to the Coq Interval package adds certified plotting, that is, the library guarantees that if a function passes through a pixel, that pixel is filled[2]. There's also the user-friendly Coquelicot[3] real analysis library up to basic differential equations (e.g. Bessel function).

> It'll rearrange an equation but I can't ask it "prove this is increasing"

For a taste, here's my proof that the cube function is increasing[4]. If I wanted to create a tactic that automatically proves a function is increasing, I would use properties of increasing functions[5] to recursively break it down into trivial subcases.

[0] https://github.com/siraben/math-3100/blob/master/analysis.v

[1] https://github.com/coq-community/corn

[2] https://coq.discourse.group/t/interval-4-2-now-with-plotting...

[3] https://hal.inria.fr/hal-00860648v1/document

[4] http://ix.io/3rxD

[5] https://www.math24.net/increasing-decreasing-functions#h-pro...