Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754013Ab1FMSHL (ORCPT ); Mon, 13 Jun 2011 14:07:11 -0400 Received: from mail-pz0-f46.google.com ([209.85.210.46]:65375 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753323Ab1FMSHJ convert rfc822-to-8bit (ORCPT ); Mon, 13 Jun 2011 14:07:09 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=OmOIr6f9OOXdLYIAtA4X7L5HzIDqczvw8jB2JaJ9dMob+WiAnzmxjR8k78nJubl7Xe 6QdLBvr7prwsUrKAicq66psLBvYvX4su9mp21qzNbrJ5UCIERw610+bYs+ywR4aIXpLO Zv27fwb/TJUGqDsgsskp5eLNBn9DIurCMeMlY= MIME-Version: 1.0 In-Reply-To: References: <1307777464.25182.3.camel@localhost.localdomain> From: Andrew Lutomirski Date: Mon, 13 Jun 2011 14:06:49 -0400 X-Google-Sender-Auth: 8NvoxNnMIOHhrGmPl5l-_CCu4ac Message-ID: Subject: Re: [PATCH] x86, vsyscall: Fix build warning in vsyscall_64.c To: Rakib Mullick Cc: mingo@elte.hu, hpa@zytor.com, tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2013 Lines: 45 On Mon, Jun 13, 2011 at 4:45 AM, Rakib Mullick wrote: > On Mon, Jun 13, 2011 at 10:54 AM, Rakib Mullick wrote: >> On Mon, Jun 13, 2011 at 8:52 AM, Andrew Lutomirski wrote: >>> On Sun, Jun 12, 2011 at 1:12 AM, Rakib Mullick wrote: >>>> On Sat, Jun 11, 2011 at 5:01 PM, Andrew Lutomirski wrote: >>>>> On Sat, Jun 11, 2011 at 3:31 AM, Rakib Mullick wrote: >>> >>> I think there are three separate issues here: >>> >>> 1. Can ret be used uninitialized? ?I say no, even as seen by the >>> compiler. ?If vsyscall_nr is 0, 1, or 2, then ret is initialized. ?If >>> vsyscall_nr is 3, then the BUG gets hit. ?BUG is defined as some >>> assembly magic followed by unreachable(), and the compiler is supposed >>> to know that code after unreachable() is qunreachable. ?So how can ret >>> be used uninitialized? >>> >> I don't have much knowledge of advance assembly, so I really don't >> understand that part - how BUG handles this. If it really makes sure >> that, it will handle it properly then I think you can drop this patch. >> >>> What version of gcc do you have? ?gcc (GCC) 4.6.0 20110530 (Red Hat >>> 4.6.0-9) does not produce this warning. >>> >> Currently, I'm replying from outside my home. I'll let you know when >> I'm back home. >> > Here is my GCC version - gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) > (GCC). I'm using Fedora 14. I also have gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) on another box, and I still can't reproduce this. Can you tell me which git revision you're building and send me your .config and the output of: $ touch arch/x86/kernel/vsyscall_64.o $ make V=1 arch/x86/kernel/vsyscall_64.o Thanks, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/