# Do Verified Memory Bounds Survive Compilation?

DevFeed: [Do Verified Memory Bounds Survive Compilation?](<https://devfeed.tech/articles/keleusma-research-spike-what-a-verified-bound-says-about-the-code-that-actually-runs-39754.md>)

Original publisher: [Read original article](<https://sgeos.github.io/engineering/compilers/verification/2026/08/08/do_proven_bounds_survive_compilation.html>)

Author: Brendan Sechter

Published: 2026-08-08T09:00:00Z

Content type: article

Language: en

Sources: [Brendan A R Sechter's Development Blog](<https://devfeed.tech/sources/brendan-a-r-sechter-s-development-blog.md>)

Topics: [Compiler](<https://devfeed.tech/topics/compiler.md>)

Tags: [compiler](<https://devfeed.tech/tags/compiler.md>), [compilers](<https://devfeed.tech/tags/compilers.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [verification](<https://devfeed.tech/tags/verification.md>)

## AI overview

This case study examines whether a verified memory bound remains applicable after compilation. An erratum corrects earlier measurements: on the measured corpus and shipped pipeline, the proven bound was empirically conservative, but this does not establish soundness because the bound and compiled frame measure different quantities.

## Source excerpt

Erratum, 2026-08-12 The empirical sections of this article measured code that had never been optimised, and the corrected figures reverse the direction of the finding. The measurement invoked the back end at two optimisation levels over the same intermediate representation. The pass that promotes stack slots into registers is a middle-end pass and the back end does not run it, so both figures described unpromoted code and the difference between them was back-end noise. Three claims made below are wrong and are corrected in place, with the original figures retained so the change is visible. The optimiser eliminates the provisioning, and does not relocate it into spill slots. Promoted then lowered, the same 19 modules occupy 5,048 bytes of frame against the 275,432 bytes reported here for unpromoted code, a factor of 54. The proven bound exceeds the real frame in every module measured, rather than falling short of it. The ratios run from 0.12 to 0.88. The article's claim that this fails in the dangerous direction is the reverse of what happens. The provisioning change reported elsewhere as a large saving buys nothing for the shipped pipeline, since promotion had already removed the dead allocations. This does not rescue the bound. Eight modules agree that it exceeds the frame and no mechanism guarantees that. The two quantities are in different units, count different things and are decided by different agents, so the agreement is coincidence and not construction. The supportable statement is that the bound is empirically conservative on this corpus under the shipped pipeline, which is much weaker than sound. The structural contribution is unaffected, being the three-part split of the bound set out in Result 1, the literature survey, and the timing result with its stated weakness. Somebody proves a program can never use more than a certain amount of memory. Then a compiler rewrites that program into a different form before it runs. Does the proof still apply? The answe