From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11608 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: more on missing volatile qualifications Date: Sun, 25 Jun 2017 12:17:04 +0200 Message-ID: <20170625101704.GA2032@port70.net> References: <20170625104516.17ac9466@inria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1498385843 3042 195.159.176.226 (25 Jun 2017 10:17:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Jun 2017 10:17:23 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) To: musl@lists.openwall.com Original-X-From: musl-return-11621-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 25 12:17:17 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dP4bT-0000Mh-4R for gllmg-musl@m.gmane.org; Sun, 25 Jun 2017 12:17:15 +0200 Original-Received: (qmail 30336 invoked by uid 550); 25 Jun 2017 10:17:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30318 invoked from network); 25 Jun 2017 10:17:16 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20170625104516.17ac9466@inria.fr> Xref: news.gmane.org gmane.linux.lib.musl.general:11608 Archived-At: * Jens Gustedt [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)