From patchwork Wed Nov 12 15:34:33 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 5290581 Return-Path: X-Original-To: patchwork-linux-sparse@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 6778A9F440 for ; Wed, 12 Nov 2014 15:34:47 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6C8AB201C0 for ; Wed, 12 Nov 2014 15:34:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CEABF201D3 for ; Wed, 12 Nov 2014 15:34:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752748AbaKLPeg (ORCPT ); Wed, 12 Nov 2014 10:34:36 -0500 Received: from mail-la0-f53.google.com ([209.85.215.53]:38365 "EHLO mail-la0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752726AbaKLPef (ORCPT ); Wed, 12 Nov 2014 10:34:35 -0500 Received: by mail-la0-f53.google.com with SMTP id mc6so11372863lab.26 for ; Wed, 12 Nov 2014 07:34:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/AL3Bj0qF7MC/FsqFvIpZO7rOFkp3mMtn80S2qIi4eA=; b=D46Cj1KbaEDDlZR/JX3okbl+pjFm9LAXHTmV86eLBK6V/h8dpQWc0D0D5JTQh0CXDa W0/jE3EY41yG8uNItHAofTCxwJwc+5wACkwQ6jKTwCzTgT1gFnDhekEKyt++7rDDbUdP GZ8bbo8r43+4LDEfvuvzg9U5u9gqbfq4g9b/Yx8TffJFb0zgovH/dLXs02412+JCN/JT 20J9JCtynIfQj160byHuI/iyRtscmypabrAAdFi5IHvj8dITxW+E/KBOdHA13Lz6odGA S0nP4tZp9p64a241XbbqF22r85vrGnLlpgMAEAEYSXLN7reHyWt3rBwgFt2UoTv5dfKg GZxw== X-Gm-Message-State: ALoCoQlBbGyXjDgYhLxe0yzhUHyABfqXAjDFgptUD6Hc/WYA5FD7LWz89ODlebg6XMsfSjq/JNkz MIME-Version: 1.0 X-Received: by 10.152.22.74 with SMTP id b10mr42799202laf.16.1415806473717; Wed, 12 Nov 2014 07:34:33 -0800 (PST) Received: by 10.112.84.67 with HTTP; Wed, 12 Nov 2014 07:34:33 -0800 (PST) In-Reply-To: References: <201411120724.PdeIjimc%fengguang.wu@intel.com> <1415799312.14686.332.camel@mfleming-mobl1.ger.corp.intel.com> Date: Wed, 12 Nov 2014 16:34:33 +0100 Message-ID: Subject: Re: [efi:next 2/3] arch/x86/boot/compressed/eboot.c:26:16: sparse: incorrect type in return expression (different modifiers) From: Ard Biesheuvel To: Christopher Li Cc: Matt Fleming , "linux-efi@vger.kernel.org" , Linux-Sparse , "fengguang.wu" Sender: linux-sparse-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 12 November 2014 16:22, Christopher Li wrote: > On Wed, Nov 12, 2014 at 9:35 PM, Matt Fleming wrote: >> (Pulling sparse list in) >> >> On Wed, 2014-11-12 at 11:31 +0100, Ard Biesheuvel wrote: >>> > tree: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git next >>> >>> arch/x86/boot/compressed/eboot.c:26:16: sparse: incorrect type in return expression (different modifiers) >>> > arch/x86/boot/compressed/eboot.c:26:16: expected struct efi_config const [pure] * >>> > arch/x86/boot/compressed/eboot.c:26:16: got struct efi_config *static [toplevel] efi_early >>> > >>> >>> This smells like a sparse bug: __pure applies to functions only, so >>> there is no way we could ever return something with the __pure >>> modifier attached. > > That make sense. > >> >> Yes, that warning does look a little strange. >> >> Christopher, Fengguang, what do you guys think? >> > > Do you get me a small test function that reproduce the error with sparse? > > We can even add a test case for it. > Well, I spent some time playing around with this: This one is accepted: static __attribute__((__pure__)) int pure1(void) { int i = 0; return i; } This one is not accepted: static __attribute__((__pure__)) void *pure2(void) { void *i = (void *)0; return i; } and produces pure.c:11:16: warning: incorrect type in return expression (different modifiers) pure.c:11:16: expected void [pure] * pure.c:11:16: got void *i I also noticed that the following triggers a warning as well: static void*(*f)(void) = pure2; (using the definition of pure2 as above) pure.c:14:26: warning: incorrect type in initializer (different modifiers) pure.c:14:26: expected void *( *static [toplevel] f )( ... ) pure.c:14:26: got void [pure] *( static [toplevel] * )( ... ) i.e., you are not allowed to assign a pointer to a pure function to a non-pure function pointer, which is quite ok. The opposite should be an error, though. This patch if (typediff) goto Err; return 1; fixes the first issue, but I am not sure if it is an appropriate fix or not. diff --git a/evaluate.c b/evaluate.c index a5a830978bda..2e9ad8b7b31d 100644 --- a/evaluate.c +++ b/evaluate.c @@ -1375,7 +1375,7 @@ static int compatible_assignment_types(struct expression *expr, struct symbol *t goto Cast; } /* It's OK if the target is more volatile or const than the source */ - typediff = type_difference(&t->ctype, &s->ctype, 0, mod1); + typediff = type_difference(&t->ctype, &s->ctype, 0, mod1 | MOD_PURE);