[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170625101704.GA2032@port70.net>
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.
