Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753159Ab1CNM5N (ORCPT ); Mon, 14 Mar 2011 08:57:13 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:45620 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752092Ab1CNM5J (ORCPT ); Mon, 14 Mar 2011 08:57:09 -0400 Date: Mon, 14 Mar 2011 13:56:46 +0100 From: Ingo Molnar To: sedat.dilek@gmail.com Cc: Jan Beulich , "H.J. Lu" , Alan Modra , binutils , LKML , "H. Peter Anvin" , Andrew Morton , Linus Torvalds , Thomas Gleixner Subject: Re: PATCH: Add --size-check=[error|warning] Message-ID: <20110314125646.GA28851@elte.hu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.3.1 -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1476 Lines: 34 * Sedat Dilek wrote: > Nice to see there is an offer for a fix from binutils-side. Agreed. > That's why I am on linux-next to squash bugs, not to ignore "warnings" We x86 arch maintainers definitely do not ignore warnings from the assembler. Assembler warnings were pretty good historically and seldom produce false positives. > BTW "warnings", did someone tried gcc-4.6? I used a snapshot from mid February > (from Debian/experimental): My linux-next build-log and the amount of warnings > doubled or even more (unfortunately, I have thrown away that logs and binaries). > Are all of these warnings ignoreable? Which of them are really severe? Most of those are -Wunused-but-set-variable warnings, right? I'm definitely not ignoring the ones that affect the code i maintain - so they are very much useful. But if GCC broke the build unnecessarily, just to over-eagerly warn about something that worked fine before, that would be extremely counter-productive! In such a situation the Linux kernel project would likely be fed up enough to build its own sane compiler/assembler/linker combo and would aim to become entirely independent in terms of its build environment. Thanks, Ingo -- 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/