Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754728AbbEMRu5 (ORCPT ); Wed, 13 May 2015 13:50:57 -0400 Received: from mail-ig0-f173.google.com ([209.85.213.173]:37995 "EHLO mail-ig0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754673AbbEMRu4 (ORCPT ); Wed, 13 May 2015 13:50:56 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150512084415.GA6535@gmail.com> <156879.1431503013@turing-police.cc.vt.edu> <20150513102257.GB4318@gmail.com> Date: Wed, 13 May 2015 10:50:55 -0700 X-Google-Sender-Auth: c45nKHgB7MuBGB2DZNNtvxaWIFo Message-ID: Subject: Re: [tip:x86/build] x86/build: Remove -Wno-sign-compare From: Linus Torvalds To: Louis Langholtz Cc: Ingo Molnar , Valdis Kletnieks , Peter Anvin , Brian Gerst , Thomas Gleixner , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , Denys Vlasenko , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3173 Lines: 69 On Wed, May 13, 2015 at 10:33 AM, Louis Langholtz wrote: > > Are warnings about sign-comparisons an architecture specific issue? No, I think it's a combination of (a) some architectures don't end up caring too much about warnings (I guess you could call this an "architecture specific issue") (b) the real problems tend to be in gcc versions that do f*cking insane things and warn for code that cannot possibly be written better any other way. Some architectures use a very constrained set of compilers, and their set may not have the particular problem. The classic example of (b) is the whole "comparison with a constant". Gcc has gotten this wrong so many times that it's not even funny. The fact is, we often use constants with the "wrong" sign. Tough. Part of it is that signed constants are simply the only sane case, even if you then compare against unsigned variables. A compiler that complains about that is a shit compiler. It's that simple. This is why "-Wno-sign-compare" was added in the first place. People who think that you should always compare unsigned variables against unsigned constants are simply wrong. And yes, we have a lot of them inside macros. We often use macros as a way to do generics in C, so code like this: #define percpu_add_op(var, val) \ do { \ ... const int pao_ID__ = (__builtin_constant_p(val) && \ ((val) == 1 || (val) == -1)) ? \ where we do magic things if "val" is 1 or -1 (generating "inc" and "dec" respectively) is not insane. But because this is a generic thing, sometimes we pass unsigned things around, and you get that "compare 'unsigned' val against '-1'" thing. Tough. Sure, we can add random casts in these things. In this particular example, we could do things like cast both (val) and -1 to "typeof(var)" and it wouldn't be "wrong". After all, it's really just meant for a heuristic (in this case it's a "let's see if this case of addition is a trivial special case of adding -1, and we'll turn it into a smaller instruction"). So those kinds of cast things don't actually improve the code, and in many cases they actively make it less obvious. They aren't worth it. So it's a tradeoff. Which one is better: get rid of stupid warnings by using "-Wno-sign-compare" or by polluting the source code with pointless type casts? If -Wno-sign-compare had higher quality, I'd be perfectly willing to add a few pointless casts. But the problem with the gcc sign-compare warning is that it has traditionally (and apparenrly _still_) had the quality of undiluted horse-shit. Which makes it an easy decision to make: "-Wno-sign-compare" is the right solution. Shut up the crap warnings, without making the source worse. Linus -- 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/