Hello Szabolcs, On Sun, 25 Jun 2017 12:17:04 +0200 Szabolcs Nagy wrote: > pthread_once_t and pthread_spinlock_t qualifiers are > visible in the c++ name mangling if a c++ function takes > pointer to them as arguments so the change is an abi break. too bad, so we can't change these two There is a reading of the C standard that says that volatile only has implications if an object itself is such qualified, having a volatile qualified lvalue access isn't enough. I don't think that any current compiler does such weird things, but who knows where optimisers will go in the future. > > Also, I can't think of any semantics for the three, where > > opitimizing out loads or stores makes any sense, so this also > > should never see any kind of performance regression. > > there was a case in glibc when volatile caused problems: > some generic atomic macro tried to create a temporary using > > __typeof(*(p)) __tmp = *(p); > > but then __tmp become volatile and operations on it generated > useless load/stores to the stack. it could be worked around as > > __typeof( (__typeof(*(p))) *(p) ) __tmp = *(p); > > is not volatile because the cast expression is unqualified. > (musl does not have such __typeof hacks, but it is an > example where volatile caused unexpeced regression) AFAICS for the third finding in sigaction.c this would not be an issue. Since in addition this is something dealing with signal stuff, I still think that volatile would be in order, here. Thanks Jens -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::