Date: Fri, 2 Aug 2013 20:05:18 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Tijl Coosemans <tijl@coosemans.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, Jung-uk Kim <jkim@FreeBSD.org>, dumbbell@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Atomic swap and test-and-set Message-ID: <20130802195156.Q1047@besplex.bde.org> In-Reply-To: <20130802105200.29672730@kalimero.tijl.coosemans.org> References: <51F81A74.4030009@FreeBSD.org> <20130731173247.GK4972@kib.kiev.ua> <20130801055421.R2570@besplex.bde.org> <20130802105200.29672730@kalimero.tijl.coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2 Aug 2013, Tijl Coosemans wrote: > On Thu, 1 Aug 2013 06:42:21 +1000 (EST) Bruce Evans wrote: >> On Wed, 31 Jul 2013, Konstantin Belousov wrote: >>> I think that constraints for all added inlines contradict the explicit >>> requirement in the gcc documentation, which states that rmw operands >>> should be specified using the 'same location' output operand for the >>> input operand (hopefully this can be parsed). It just happens so that >>> for "m" compiler cannot do anything else then passing the address. >>> >>> The problem is not specific to the new functions, it seems to be present >>> in other functions as well, e.g. cmpset. This probably can be postponed. >> >> The problem is the opposite. The other functions used to use the '+' >> constraint to indicate input-output operands, but gcc broke this so it >> was changed in 2005. gcc.info still says fuzzily that the '+' constraint >> "should" only be used for operands that can be allocated in a register: > > That text has changed for gcc 4.8.0: > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02130.html > > It refers to a patch from 2004: > http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00438.html > > That patch appears to be in all gcc 4.x releases. Actually, only a fixed version of it seems to be there. The version of gcc-4.2.1 in FreeBSD doesn't have a Changelog entry matching msg00438.html, but it has a patch that does more. The followup to msg00438.html pointed out a problem in the original patch (that it generates a matching input constraint too blindly and thus breaks the case of multiple alternatives). This seems to be fixed in the version in FreeBSD, but the followup stops at that point. So the pointer to the patch seems to be off by 1. msg02130.html gives the fuzzier pointer "back in 2004". These are still better in log messages than vcs-specific revision numbers. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130802195156.Q1047>