On Wed, May 15, 2013 at 9:50 AM, Florian Weimer <fwei...@redhat.com> wrote: > Back when these attributes were defined, we had no inter-procedural analysis > or other fanciness, so I suspect we didn't consider the case where the > annotated function only behaved as if it were pure or const. One important > case is memoization—a function which uses this technique writes to global > memory (so that the computed result can be reused by a future call), but > calls to it can be freely scheduled, replicated or removed (for const; for > pure, writes to global memory have to be taken into account). > > Is it permitted to use pure/const for such functions? What should our > documentation say?
Well ... const / pure annotation is a promise to the compiler and the compiler uses the annotation to decide validity of transforms of the calls. The documentation specifies that in terms of what such function can do because that's possibly less confusing to developers. So, yes - if a function call can be freely scheduled/replicated or removed then it is const, if it can be freely replicated, removed but not scheduled across writes it is pure. Now - if there would ever be an architecture where special call-site preparation is required for a callee to write to global memory then marking a function 'const' when it does in fact write to global memory then GCC may choose to optimize the call site to not do that call-site preparation. At least that would be valid according to the current documentation. Which means, annotating a function as const / pure in the way you mean to is safe currently, but to make it safe in the future can you try to formulate an amendmend to the documentation that defines such annotations as valid? (I can think of effects on transactional memory or the C++ memory model, so it needs to be required that the memory the function reads/writes never conflicts (be in the same cache-line?) with memory used otherwise?) Richard. > -- > Florian Weimer / Red Hat Product Security Team
