Date: Tue, 09 Jun 2015 09:23:51 +0200 From: Sebastian Huber <sebastian.huber@embedded-brains.de> To: freebsd-hackers@freebsd.org Subject: Re: [PATCH] timecounters: Fix timehand generation read/write Message-ID: <55769487.20901@embedded-brains.de> In-Reply-To: <20150604181041.GC11630@britannica.bec.de> References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> <20150603203228.GA9774@britannica.bec.de> <2023236942.13088.1433365253885.JavaMail.zimbra@embedded-brains.de> <20150604181041.GC11630@britannica.bec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/06/15 20:10, Joerg Sonnenberger wrote: > On Wed, Jun 03, 2015 at 11:00:53PM +0200, Sebastian Huber wrote: >> In my interpretation of the C standard this is implementation defined = behaviour. See also: >> >> https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html > I don't think that is nearly correct as far as any data accessibly from > global objects is concerned beside the volatile. C11 5.1.2.3 (2) and (3= ) > are the relevant clauses. An assignment to a volatile object is a > sequence point with side effects. All assignments before that sequence > point must be visible to whatever possible side effect the volatile has= . > Similar, it can implicitly change all globals, so no read can be moved > from after the sequence point to before. This is much stricter than the > normal as-if rule, since a sequence of side-effect-free operations can > be implemented anyway the compiler likes. A different interpretation > would be quite questionable. > > Note that this is all just about the rules of the C abstract machine. I= t > is not about the observable behavior of a multi-processor machine. > Whether or not TSO is enough for this purpose is a completely different > question. I didn't want to start a discussion about the C standard interpretation.=20 GCC generates code according to their documentation: https://lists.freebsd.org/pipermail/freebsd-hackers/2015-May/047778.html In case you think GCC is doing something wrong, then maybe you can file=20 a bug report for GCC. Anyway we need real memory barriers. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=E4ftliche Mitteilung im Sinne des EHUG.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55769487.20901>