Paul Eggert <[email protected]> writes: > On 8/8/26 05:38, Sam James wrote: >> The comment simply isn't right and it makes an assertion that doesn't >> reflect reality. It is not validly const if it uses global memory to >> affect what it returns, even if later calls are OK. > > But __eloop_threshold doesn't use global memory to affect what it returns. It > always returns the same value, every time. So, even though __eloop_threshold > uses static storage (I assume that's what you mean by "global memory"), its > use > of that static storage doesn't affect what it returns. > > In this sense I guess __eloop_threshold differs from a common C++ idiom, in > which even though the function always returns the same value, that value is > affected by what's already in memory. __eloop_threshold does not have that > property. > > If my understanding is incorrect I'd appreciate a clarification, e.g., an > example of an optimization that GCC might apply that would be invalid for > __eloop_threshold.
I'm not certain that [[gnu::const]] is correct (FWIW, I can't think of how it'd go wrong, but anyway), but I am certain this is a race condition in linkat etc due to this condition. ;) Those should be atomic accesses. -- Arsen Arsenović
signature.asc
Description: PGP signature
