Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1073968pxb; Wed, 27 Oct 2021 18:50:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJye4EBpFrX4EzWq2m7SaPaNdRtwYV4FHB2VrfdOgyGX1fCQrTQg3cwCrtHaFURbcZ/WamQQ X-Received: by 2002:aa7:c952:: with SMTP id h18mr2109226edt.18.1635385853567; Wed, 27 Oct 2021 18:50:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635385853; cv=none; d=google.com; s=arc-20160816; b=iY04hgPL0bh15BqCkqBi22seB0Y0/7UgoY5MX6tK57HRVg9uf7iAyqUDe+Uj6QI/e/ efd5BuYeZ0l/XHX+U0U8rigGAySDTAQ9W9Um9YE2678ekudHAFvxmud6DzTFCGG90qsA FwxUk5LsoL01+gAdH736tXFQ7Ge2fkhFsBp8QLVZe9bnDfcao5cQAAn7MRkmo2M6abup 9VLhkkrYy2aTnvFOemjKicd7NyXY3f4fXvP1ymOGvO7THE9snbx8wAm/ttlmB9Q3i4cr 9EoF01yOgWBqC5ZRx5HlEI9Oe7ZXQbH1SQyegDqpac3/IQnK4ozehNCcfGdPFuJyxQIy ih9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=S9qNzhuSE3E47WcWOKm+N6VWE/DGhTgLZASmiUQGaMA=; b=GJsIRfyhXzZxZEqJLzIt3XpHEnnRySAVmaw9lTUsu85jVZsqPkTUwCQjcL06qUIYPD BKHcCOmeZR6K+1TqFQo9qZQ4i4tZhb4EEWJnWFqYjfJ9ibi6ypMsaIHHvadqumIrjfFl d/WupywCX95bJKXbVcSbkd7MkHAeFO3nqDjkdIXg5Ilws4SwMoNxtERYSRQJEEq6KiuQ 3AJoZ7S7H1dH5FGfO30CzugQPobtKJdNCPOtDgEgxp/33tzeQma5uK+OZ75fNHGBhHaY fx8qhNcx5soeyd+VoIXUFYpHgkIjpaZglxd+/E/ZCzRObD0wfwj6nNvrNBzInCWynW01 kFdA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cs10si2461687ejc.569.2021.10.27.18.50.30; Wed, 27 Oct 2021 18:50:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229636AbhJ1Bt7 (ORCPT + 99 others); Wed, 27 Oct 2021 21:49:59 -0400 Received: from netrider.rowland.org ([192.131.102.5]:48063 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S229534AbhJ1Bt6 (ORCPT ); Wed, 27 Oct 2021 21:49:58 -0400 Received: (qmail 1337702 invoked by uid 1000); 27 Oct 2021 21:47:31 -0400 Date: Wed, 27 Oct 2021 21:47:31 -0400 From: Alan Stern To: Willy Tarreau Cc: Kernel development list Subject: Re: GCC not detecting use of uninitialized variable? Message-ID: <20211028014731.GA1337521@rowland.harvard.edu> References: <20211027201249.GA1326060@rowland.harvard.edu> <20211027204831.GB12219@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211027204831.GB12219@1wt.eu> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 27, 2021 at 10:48:31PM +0200, Willy Tarreau wrote: > On Wed, Oct 27, 2021 at 04:12:49PM -0400, Alan Stern wrote: > > The following code does not generate a warning when compiled with GCC > > 11.2.1: > > > > > > int foo; > > > > void cc_test(void) > > { > > int a, b; > > > > a = 0; > > a = READ_ONCE(foo); // Should be: b = READ_ONCE(foo) > > do { > > a += b; > > b = READ_ONCE(foo); > > } while (a > 0); > > WRITE_ONCE(foo, a); > > } > > > > > > But if the loop is changed to execute only once -- replace the while > > test with "while (0)" -- then gcc does warn about the uninitialized use > > of b. > > > > Is this a known problem with gcc? Is it being too conservative about > > detecting uses of uninitialized variables? > > I already had similar issues not being detected in loops. I guess the > reason is simple: it might not be trivial for the compiler to prove > that the value was not set on any path leading to the first use, > because one of these paths is the loop itself after the instruction was > assigned. I've been so much used to it that I think it has always been > there and I can live with it. Well, in this case there's only one path leading to the first use, since the path that is the loop itself will never be the first use. It seems like a rather surprising oversight. Maybe I'll try asking the GCC people about this... Thanks, Alan Stern