From patchwork Mon Sep 14 17:27:40 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christopher Li X-Patchwork-Id: 47352 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n8EHRguR027604 for ; Mon, 14 Sep 2009 17:27:42 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751250AbZINR1i (ORCPT ); Mon, 14 Sep 2009 13:27:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751569AbZINR1i (ORCPT ); Mon, 14 Sep 2009 13:27:38 -0400 Received: from mail-vw0-f195.google.com ([209.85.212.195]:34983 "EHLO mail-vw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751250AbZINR1h (ORCPT ); Mon, 14 Sep 2009 13:27:37 -0400 Received: by vws33 with SMTP id 33so530308vws.33 for ; Mon, 14 Sep 2009 10:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=st1kBa5N8WKdPZFuRdLLwGQ7Ps2FII6sxet9cRNj1ZQ=; b=Tabw7nqE92kSVB+PfJsjDQMSW+RvsMgK2Rk3HnqN6GnMu1BUoSz+IyCK9Ligaz4ZKW ZTMJORlLCXi/hNsCr1KXqzRxyZJ9zYUUqcMZk95zhlgPMgVRr6j6T3N7VKSzZshlbXyl yZMX293AHHxYgcTiy0A67Qmsl9AGiaA0xIHF4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Cd1IQ0ptQTo/Zydlp3BdFU0Sl7QCBuJvIdiWOdy/FJ9kvwfsaxy29iNa9TTohaP3U7 7eQNEusgLEWSqXOL3zZBgb+yRgX+azA3soaxYG90KMIeEDuaPNeki/0g8eIkk67EcBu+ ocWJMj/Pun+5n6RfHdEMF8bJIilA3PBZz/0kk= MIME-Version: 1.0 Received: by 10.220.15.68 with SMTP id j4mr8638072vca.18.1252949261009; Mon, 14 Sep 2009 10:27:41 -0700 (PDT) In-Reply-To: <70318cbf0908281444q735b7b9fm73f0fcbdbaeefa7b@mail.gmail.com> References: <200908282330.08332.kdudka@redhat.com> <70318cbf0908281444q735b7b9fm73f0fcbdbaeefa7b@mail.gmail.com> Date: Mon, 14 Sep 2009 10:27:40 -0700 X-Google-Sender-Auth: 78100f82c8d98ee7 Message-ID: <70318cbf0909141027y69ddecc2y591ffb6aca300fca@mail.gmail.com> Subject: Re: [PATCH] do not ignore attribute 'noreturn'... From: Christopher Li To: Kamil Dudka Cc: linux-sparse@vger.kernel.org Sender: linux-sparse-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org On Fri, Aug 28, 2009 at 2:44 PM, Christopher Li wrote: > Yes, no return is kind of useful. I think we need to do some thing about the > MOD_XXX eventually. It is very easy to run out of bits there. > Ah, the MOD_NORETURN is bigger than size of long in 32 bit systems. I just get a few warning from GCC. I just relocate the MOD_NORETURN bits. Chris --- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/symbol.h b/symbol.h index 80ef363..9f5a32f 100644 --- a/symbol.h +++ b/symbol.h @@ -214,10 +214,10 @@ struct symbol { #define MOD_SAFE 0x8000000 // non-null/non-trapping pointer #define MOD_USERTYPE 0x10000000 +#define MOD_NORETURN 0x20000000 #define MOD_EXPLICITLY_SIGNED 0x40000000 #define MOD_BITWISE 0x80000000 -#define MOD_NORETURN 0x100000000 #define MOD_NONLOCAL (MOD_EXTERN | MOD_TOPLEVEL) #define MOD_STORAGE (MOD_AUTO | MOD_REGISTER | MOD_STATIC | MOD_EXTERN | MOD