Date: Sun, 25 Jun 2017 12:17:04 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: more on missing volatile qualifications * Jens Gustedt <jens.gustedt@...ia.fr> [2017-06-25 10:45:16 +0200]: > > - the definition of pthread_once_t > - the definition of pthread_spinlock_t > - the handler array in sigaction.c > > All three could benefit for an additional volatile qualification. All > their usages are already so, so this would just be conservative and > not risk any incompatibilities, I think. 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. > 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)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.