From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753925AbbFZO31 (ORCPT ); Fri, 26 Jun 2015 10:29:27 -0400 Received: from mail-yk0-f169.google.com ([209.85.160.169]:35488 "EHLO mail-yk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751857AbbFZO3D (ORCPT ); Fri, 26 Jun 2015 10:29:03 -0400 Date: Fri, 26 Jun 2015 10:28:58 -0400 From: Tejun Heo To: Geert Uytterhoeven Cc: Jens Axboe , torvalds@linuxfoundation.org, "linux-kernel@vger.kernel.org" Subject: Re: [GIT PULL] Cgroup writeback support for 4.2 Message-ID: <20150626142858.GD15805@mtj.duckdns.org> References: <20150625144432.GD13739@kernel.dk> <20150626134314.GB15805@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Geert. On Fri, Jun 26, 2015 at 03:57:18PM +0200, Geert Uytterhoeven wrote: > > Can you please tell me the version of gcc which triggered the above > > warnings? > > gcc 4.1.2 I see. I read wrong. > That's why I keep on using gcc 4.1.2: it still gives build warnings for > many "used uninitialized" cases that later gcc versions let pass silently. > > Granted, some of these are false positives (that's why it was disabled in > later gcc versions), but some of these are valid and real bugs. That's kinda surprising. My impression has been that later gcc versions are doing a lot better job both at actually detecting problematic ones and avoiding false positives. I'm surprised that 4.1.2 is still catching uninitialized usages later gcc's (and other static analyzers) can't. Can you roughly say how often it detects actual problems that later ones can't? > Anyway, as a casual reader, it took me a while to notice all four warnings > listed above are false positives... 4.1.2 is more than 8 years old at this point. I really don't want to kludge the code w/ unnecessary initializations as that'll actually harm our ability to detect actual problems. The only option would be refactoring the code so that larger blocks of code are put into #ifdefed functions but I'm not really sure whether keeping 4.1.2 happy should be a guideline that we follow when organizing code. Thanks. -- tejun