There is some recent code added to Linux 4.2, that relies on disabled optimization. This might be an interesting case of unclear interpretation/misuse of the C language.
#ifdef __OPTIMIZE__ #error "The CPU Jitter random number generator must not be compiled with optimizations. See documentation. Use the compiler switch -O0 for compiling jitterentropy.c." #endif https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/crypto/jitterentropy.c Documentation: http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html 2015-06-27 1:48 GMT+02:00 Peter Sewell <peter.sew...@cl.cam.ac.uk>: > On 26 June 2015 at 20:27, Joseph Myers <jos...@codesourcery.com> wrote: >> On Fri, 26 Jun 2015, Peter Sewell wrote: >> >>> > It's s simple matter of points-to analysis. &foo + anything may be >>> > assumed (in practice) to point to something within foo (or just past the >>> > end) and not to alias anything accessed through a pointer based on &bar. >>> > If the compiler can see something like &foo + (&bar - &foo) there is no >>> > guarantee of whether it will assume it to point within foo or bar and that >>> > may not be consistent for different uses (so it may end up concluding the >>> > pointer compares unequal to itself). >>> >>> Ok, that's fine in some (perhaps most) situations, but it's not >>> compatible with what seems to be a significant body of systems code >>> out there - people mentioned important usages in FreeBSD, Linux, QEMU, >>> and other places. How can these be reconciled? We imagine: >> >> Does that code actually access the same object via both routes in code >> that might get moved past each other (or values get reused because the >> compiler didn't think they could have changed) as a consequence of the >> points-to analysis? If the aliasing isn't visible, it's less likely to >> cause problems. > > It's a good question - quite possibly not, though it's hard to > investigate; really we have no idea. But I'm not sure how we could > state a condition like that precisely in some reasonable way, and if > the conditions under which this is safe become too complex, that in > itself becomes a failing in the language definition - at the end of > the day, it has to be comprehensible. > > More generally, the programming-language design tradeoff between > simplicity on the one hand and performance and expressivity on the > other is always a difficult thing to manage. The wide range of > opinions out there about what C behaviour can be relied on suggests > that C may have veered too far to the latter in some respects. > >>> a) Compilation of that systems code could turn off this analysis (and >>> whatever optimisation depends on it) entirely. What's the cheapest >>> way to do that? >> >> I think -fno-tree-pta should disable it (I don't know what the cost of >> that is). > > thanks, > Peter > > >> -- >> Joseph S. Myers >> jos...@codesourcery.com
