Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: jseigh Newsgroups: comp.arch Subject: Re: Strange asm generated by GCC... Date: Fri, 20 Dec 2024 15:17:19 -0500 Organization: A noiseless patient Spider Lines: 28 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 20 Dec 2024 21:17:19 +0100 (CET) Injection-Info: dont-email.me; posting-host="cfa45f408349cb568665e199ccce92c2"; logging-data="3792145"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+7e3oPpepSxFYKdBPttQq1" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:y01hxuNEUghtcM04VKSS/YbFvkM= Content-Language: en-US In-Reply-To: Bytes: 1944 On 12/20/24 14:59, jseigh wrote: > On 12/20/24 12:46, jseigh wrote: >> On 12/19/24 19:43, Chris M. Thomasson wrote: >>> Why in the world would GCC use an XCHG instruction for the following >>> code. The damn XCHG has an implied LOCK prefix! Yikes! >>> >> >> Speaking of strange code >> > That should be a ref paramter.  I though I updated the pasted code. > > #include > > bool test1(std::atomic& var, int addend) > { >     int expected = var.load(std::memory_order_relaxed); >     int update = expected + addend; >     return var.compare_exchange_weak(expected, update, > std::memory_order_acq_rel, std::memory_order_seq_cst); > } Alright, my bad. I should have double checked the docs. It's undefined behavior in this case. It seems like the success/failure form of compare_exchange is redundant unless you want it for self documentation. Joe Seigh