From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11609 Path: news.gmane.org!.POSTED!not-for-mail From: Jens Gustedt Newsgroups: gmane.linux.lib.musl.general Subject: Re: more on missing volatile qualifications Date: Sun, 25 Jun 2017 13:06:29 +0200 Organization: inria.fr Message-ID: <20170625130629.03dc67bc@inria.fr> References: <20170625104516.17ac9466@inria.fr> <20170625101704.GA2032@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/M0=KayRfTf0wCyVNT36D8+a"; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1498388881 5460 195.159.176.226 (25 Jun 2017 11:08:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Jun 2017 11:08:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11622-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 25 13:07:57 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 1dP5OU-00015a-LQ for gllmg-musl@m.gmane.org; Sun, 25 Jun 2017 13:07:54 +0200 Original-Received: (qmail 9300 invoked by uid 550); 25 Jun 2017 11:06:43 -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 9227 invoked from network); 25 Jun 2017 11:06:42 -0000 X-IronPort-AV: E=Sophos;i="5.39,390,1493676000"; d="scan'208";a="280511500" In-Reply-To: <20170625101704.GA2032@port70.net> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ Xref: news.gmane.org gmane.linux.lib.musl.general:11609 Archived-At: --Sig_/M0=KayRfTf0wCyVNT36D8+a Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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. =20 >=20 > there was a case in glibc when volatile caused problems: > some generic atomic macro tried to create a temporary using >=20 > __typeof(*(p)) __tmp =3D *(p); >=20 > but then __tmp become volatile and operations on it generated > useless load/stores to the stack. it could be worked around as >=20 > __typeof( (__typeof(*(p))) *(p) ) __tmp =3D *(p); >=20 > 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 --=20 :: 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 :: --Sig_/M0=KayRfTf0wCyVNT36D8+a Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCWU+ZNQAKCRAP0+hp2tU3 4v8rAJ98AcSrrL2EicWUCqugNWIF6XxIHQCfRdOvX2L53jl3Z/4irXhZ8FO4OrE= =0jax -----END PGP SIGNATURE----- --Sig_/M0=KayRfTf0wCyVNT36D8+a--