From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0794C45B2F; Sun, 13 Oct 2024 17:20:02 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A9D92402A1; Sun, 13 Oct 2024 17:20:01 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 09A8040273 for ; Sun, 13 Oct 2024 17:19:59 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 8822DC110 for ; Sun, 13 Oct 2024 17:19:59 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 7BA99C10F; Sun, 13 Oct 2024 17:19:59 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.2 Received: from [192.168.1.85] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 6F80BBFED; Sun, 13 Oct 2024 17:19:57 +0200 (CEST) Message-ID: <56e72271-2e4c-4ea4-b7b4-e7662202116c@lysator.liu.se> Date: Sun, 13 Oct 2024 17:19:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] bitops: fix issue in parallel atomic tests To: =?UTF-8?Q?Morten_Br=C3=B8rup?= , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , David Marchand Cc: dev@dpdk.org, Luka Jankovic , Thomas Monjalon References: <20241013115719.820853-1-mattias.ronnblom@ericsson.com> <98CBD80474FA8B44BF855DF32C47DC35E9F7CD@smartserver.smartshare.dk> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F7CD@smartserver.smartshare.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2024-10-13 15:37, Morten Brørup wrote: >> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com] >> Sent: Sunday, 13 October 2024 13.57 >> >> The macros generating the parallel test for atomic test-and- >> [set|clear|flip] functions used a 64-bit reference word when assuring >> no neighbouring bits were modified, even when generating code for the >> 32-bit version of the test. >> >> This issue causes spurious test failures on GCC 12.2.0 (the default >> compiler on for example Debian 12 "bookworm"), when optimization level >> 2 or higher are used. >> >> The test failures do not occur with GCC 11, 12.3 and 13.2. >> >> To the author, this looks like a promotion-related compiler bug in GCC >> 12.2. > > I am curious about the compiler bug... > > Did the bug occur when the most significant bit was set, so it sign related? > It seems to happen a lot more often than 1/32 times. Also, all involved types are unsigned. If you set the optimization level to "1" (i.e., __attribute__((optimize("O"))) on the test_bit_atomic_parallel_test_and_modify32 function, the test passes on 12.2.0. > Maybe this will reveal something: > > TEST_ASSERT(expected_word == word, > "Untouched bits have changed value, %" PRIx ## size > " should be %" PRIx64, > word, expected_word); > Confusingly enough, the failing assertion is the one prior that assertion. >> >> Fixes: 35326b61aecb ("bitops: add atomic bit operations in new API") >> >> Signed-off-by: Mattias Rönnblom >> --- > > I took a deep look into this. > > Regardless of what the compiler bug is, > > Reviewed-by: Morten Brørup > Thanks. I'm far from sure it's a compiler bug. Just look at the base rate: how often does the code you just wrote fail because of a bug in your code, and how often is the root cause to be found in the compiler or the standard libraries.