From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C252624DCF6 for ; Thu, 30 Jul 2026 05:51:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785390706; cv=none; b=GxkOLxMbE852/9WKcJ1GXsVaoMTc2SVO1Mg5dEkhCmR5kVFqK+XbUX3zgSQHBzgJLaJYQUfnN9PJheI6jUGNL79s0FHLfGCPoKQuVZro/QKfL+lk9scdMBV7adcN1z6LULt2IxQOH3gjXb8OIFKr0dme8yaFuGa8lUV5pGEQvGQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785390706; c=relaxed/simple; bh=Pcv6KLdihZsCUjKxe+9pyLwyWl6osl/y9BWFx1NmYxA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QxK6zhMtxc29tPoep5LGO9yrN5pH/LnwEvn0DPt/Ann+vFYGqe2fWntyP5AqR/Jw9+lEu95mRFPQCcQqR7mwvvYKvnbtA3WQrhb3cAerogFlabGPPzbG1j4JO8OEPJ3IT4m96Uyzcv86vmUNTsP8q7EWL6djmqjI4223REZNP6o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YiHzUuQr; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YiHzUuQr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C7161F000E9; Thu, 30 Jul 2026 05:51:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785390705; bh=UjUSchQg0I+CuqUd4I911yWy9DuxGtFCha3UjK9DHFM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=YiHzUuQrueagfhMNqF7i9zvPcMaQ/ylXYV7RTPxwlegqZl2/mAgOenL2iR6qPqJ9i cQmj3zdD27PeDddkzfww1LEJM2yx9Ygo1kMBuAE5jHNE1VKfmIPbd6cqrh22sOOlzr Hww0f9vNnw3RZ4qE0z0LfPFdwreiB9bEWr0pwJgGS65NnPUhoEyGC1/Ww4jwh283pC 1XlXsl4+pigI967z0JGiuiyuJF33ysXDu2HFMgHFNOxsMqckUNviE9t+8CskGTVUUD 2ewMQGHXeDu9P68/Fuxo325kbT2SN5YOe1w9HqdYzuG7oN3CJej4qcT0HL0cHja3P8 P4rnbvn4+hUzg== Message-ID: <5c140099-4448-4091-979a-6f6fe7d92ce8@kernel.org> Date: Thu, 30 Jul 2026 07:51:40 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/2] powerpc/sstep: Fix compilation on 32-bit PowerPC To: Link Mauve , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Cc: Madhavan Srinivasan , techflashYT , Ash Logan , =?UTF-8?Q?Jonathan_Neusch=C3=A4fer?= , Michael Ellerman , Nicholas Piggin References: <20260729204958.755143-1-linkmauve@linkmauve.fr> Content-Language: fr-FR From: "Christophe Leroy (CS GROUP)" In-Reply-To: <20260729204958.755143-1-linkmauve@linkmauve.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 29/07/2026 à 22:49, Link Mauve a écrit : > Two local variables were only set but never read on 32-bit PowerPC, > which causes an error during compilation. Are those errors new ? This series and the one from yesterday on ppc64, I have the feeling that the code is not new. Has anything changed in the building flags or does this pops up with recent versions of GCC ? If it is the case it is worth saying it in the commit messages in order to clarify the reason for the fix. > > This series first makes the 64-bit guards consistent by converting all > uses of CONFIG_PPC64 to use __powerpc64__ instead, and then guard the > two variables rc and suffix behind __powerpc64__ checks. > > Link Mauve (2): > powerpc/sstep: Consistently use one define to check arch bit width > powerpc/sstep: Don’t define variables we won’t be using > > arch/powerpc/lib/sstep.c | 26 ++++++++++++++++---------- > 1 file changed, 16 insertions(+), 10 deletions(-) > > > base-commit: 78bc8af4affb9a732504eb22eeac7d1e50883853