From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 599B3C433ED for ; Thu, 22 Apr 2021 07:52:28 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EACF86121E for ; Thu, 22 Apr 2021 07:52:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EACF86121E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.115085.219403 (Exim 4.92) (envelope-from ) id 1lZU8E-0007WQ-Ip; Thu, 22 Apr 2021 07:52:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 115085.219403; Thu, 22 Apr 2021 07:52:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZU8E-0007WJ-EY; Thu, 22 Apr 2021 07:52:14 +0000 Received: by outflank-mailman (input) for mailman id 115085; Thu, 22 Apr 2021 07:52:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZU8D-0007WE-0y for xen-devel@lists.xenproject.org; Thu, 22 Apr 2021 07:52:13 +0000 Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f4cf9117-f2ad-4d32-9d7a-9618c5c9fdfe; Thu, 22 Apr 2021 07:52:12 +0000 (UTC) Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1lZU8A-000OFc-M4; Thu, 22 Apr 2021 07:52:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f4cf9117-f2ad-4d32-9d7a-9618c5c9fdfe Date: Thu, 22 Apr 2021 08:52:10 +0100 From: Tim Deegan To: Andrew Cooper Cc: Xen-devel , Jan Beulich , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Wei Liu Subject: Re: [PATCH 6/7] x86/shadow: Make _shadow_prealloc() compile at -Og Message-ID: References: <20210419140132.16909-1-andrew.cooper3@citrix.com> <20210419140132.16909-7-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20210419140132.16909-7-andrew.cooper3@citrix.com> X-SA-Known-Good: Yes X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tim@xen.org X-SA-Exim-Scanned: No (on deinos.phlegethon.org); SAEximRunCond expanded to false At 15:01 +0100 on 19 Apr (1618844491), Andrew Cooper wrote: > When compiling at -Og: > > In file included from > /builds/xen-project/people/andyhhp/xen/xen/include/asm/domain.h:4:0, > from /builds/xen-project/people/andyhhp/xen/xen/include/xen/domain.h:8, > from /builds/xen-project/people/andyhhp/xen/xen/include/xen/sched.h:11, > from /builds/xen-project/people/andyhhp/xen/xen/include/xen/ioreq.h:22, > from common.c:23: > common.c: In function '_shadow_prealloc': > /builds/xen-project/people/andyhhp/xen/xen/include/xen/mm.h:252:55: error: 't' may be used uninitialized in this function [-Werror=maybe-uninitialized] > return page != head->next ? pdx_to_page(page->list.prev) : NULL; > ^ > common.c:933:28: note: 't' was declared here > struct page_info *sp, *t; > ^ > > I'm not certain the analysis is correct. 't' is a temporary variable, and is > clearly initialised before use in foreach_pinned_shadow(). Either way, > initialising it to NULL placates the compiler. Yeah, this analysis seems wrong to me too - if nothing else, why does it not complain about the identical code in shadow_blow_tables() below? That said, since the non-debug build doesn't complain here, presumably it will be able to elide this dead store. Acked-by: Tim Deegan