From: Arnd Bergmann <arnd@arndb.de>
To: Dave Jones <davej@redhat.com>
Subject: Re: 2.6.14 assorted warnings
Date: Fri, 28 Oct 2005 10:07:41 +0200
User-Agent: KMail/1.7.2
Cc: Keith Owens <kaos@ocs.com.au>, linux-kernel@vger.kernel.org
References: <5455.1130484079@kao2.melbourne.sgi.com> <20051028073049.GA27389@redhat.com>
In-Reply-To: <20051028073049.GA27389@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Message-Id: <200510281007.42758.arnd@arndb.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 976
Lines: 26

On Freedag 28 Oktober 2005 09:30, Dave Jones wrote:
> gcc is dumb, it doesn't realise that the variable will be filled by another
> function if its passed thus..
> 
> ????????unsigned long foo
> ????????bar(&foo)
> ????????if (foo==1)
> ????????????????...
> 
> With bar() filling in content of foo.
> I believe there's at least once instance of this in gcc bugzilla.
> 
The case is more complicated here. gcc before 4.0 always assumed that
bar(&foo); initializes foo. gcc-4.0 now looks into bar if it is inlining
that and tries to find out if that really initializes foo in every
case.

In the example, bvec_alloc_bs does not initialize &idx when nr is not
between 1 and BIO_MAX_PAGES, so gcc is telling the truth here.

	Arnd <><
-
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/