Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7799C6FD1D for ; Mon, 20 Mar 2023 22:54:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229768AbjCTWyW (ORCPT ); Mon, 20 Mar 2023 18:54:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229453AbjCTWyU (ORCPT ); Mon, 20 Mar 2023 18:54:20 -0400 Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D7D93B749; Mon, 20 Mar 2023 15:54:18 -0700 (PDT) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 32KMmfUC015937; Mon, 20 Mar 2023 17:48:41 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 32KMmevv015936; Mon, 20 Mar 2023 17:48:40 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 20 Mar 2023 17:48:40 -0500 From: Segher Boessenkool To: Nathan Chancellor Cc: Linus Torvalds , Guenter Roeck , Linux Kernel Mailing List , David Airlie , Daniel Vetter , dri-devel@lists.freedesktop.org, linux-toolchains@vger.kernel.org, llvm@lists.linux.dev Subject: Re: Linux 6.3-rc3 Message-ID: <20230320224840.GG25951@gate.crashing.org> References: <20230320180501.GA598084@dev-arch.thelio-3990X> <4adbed5a-6f73-42ac-b7be-e12c764ae808@roeck-us.net> <20230320220631.GA637514@dev-arch.thelio-3990X> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230320220631.GA637514@dev-arch.thelio-3990X> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 20, 2023 at 03:06:31PM -0700, Nathan Chancellor wrote: > It seems like clang takes into account that the branch has no effect on > how uninitialized err is, although it does acknowledge there may be > control flow where err is not used uninitialized because it is not used > at all by stating "when used here". I guess GCC does not make this > distinction and places it under -Wmaybe-uninitialized. I could be > totally wrong though :) In one place we have the comment /* Re-do the plain uninitialized variable check, as optimization may have straightened control flow. Do this first so that we don't accidentally get a "may be" warning when we'd have seen an "is" warning later. */ It seems we miss a similar case here? In any case, please open a PR if you want this fixed. Thanks! Segher