So where would these "resolved issues" be documented? I first thought they would also be "litmus tests", the only different being that we already settled on an answer for their validity.
One thing I am missing here is: What's the right place (in the repo) for "general principles" we'd like to adopt. For example, we may want to decide that removing scopes ({...}
) should not affect the validity of a piece of code, so e.g. the following two programs would be equi-valid:
{ let x = ...; let y = ... ; ... ; } let z = ...; ...
let x = ...; let y = ... ; ... ; let z = ...; ...
There are a whole lot of other source-to-source transformations I can imagine, and it may well turn out that that some of them have surprising effects on what is (not) allowed. I guess we could put them together with the "optimizations", though many of the latter will not even be expressible as source-to-source transformation (they may only by expressible in MIR/LLVM).
We have to be careful here, CompCert makes a whole lot of behavior defined that is undefined in plain C. This is fine for CompCert (the compiler just has less opportunity for optimization), but it makes CompCert unsuited to reason about C UB in general. Maybe a better place for that is this PhD thesis, which makes an actual attempt to define all UB in C: http://robbertkrebbers.nl/thesis.html
Definitely, that's very interesting work! I talked with the authors recently, and it seems there is a new version coming up soon (that's academia-soon
). I also was told that there are efforts underway to change the semantics of LLVM itself (it seems that undef
is pretty broken currently; there are optimization which turn one use of a variable into two uses of the same variable assuming it will have the same value, which is just not true if the value is undef
). I've been watching LLVM Weekly ever since then, but couldn't find any more details.
However, VeLLVM does not attempt to precisely model LLVM at all cost, so we have to watch out for subtleties here. (I guess typically these will be subtleties which are not covered by the LLVM documentation and which even the LLVM community does not have a coherent view of.) And finally, I was told I shouldn't hold my breath for VeLLVM to support LLVM's aliasing annotations anytime soon, which are unfortunately among the most interesting bits of LLVM semantics when it comes to unsafe code interacting with borrow types -- and again, the documentation doesn't say much either. This is related to C's restrict
being poorly understood, on a formal sense.