From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8603 invoked by alias); 5 Dec 2006 22:24:32 -0000 Received: (qmail 8581 invoked by uid 22791); 5 Dec 2006 22:24:31 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Dec 2006 22:24:26 +0000 Received: (qmail 14905 invoked from network); 5 Dec 2006 22:24:24 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Dec 2006 22:24:24 -0000 To: gdb-patches@sourceware.org Cc: Mark Kettenis Subject: Re: PATCH: Initialize tmp_obstack References: <20061202182712.GA623@lucon.org> <20061205204003.GB25572@nevyn.them.org> <12601.163.1.150.229.1165354805.squirrel@webmail.xs4all.nl> <20061205214306.GA29801@nevyn.them.org> <20637.163.1.150.229.1165355320.squirrel@webmail.xs4all.nl> <20061205215639.GA30371@nevyn.them.org> <20061205215858.GA30808@nevyn.them.org> From: Jim Blandy Date: Tue, 05 Dec 2006 22:24:00 -0000 In-Reply-To: <20061205215858.GA30808@nevyn.them.org> (Daniel Jacobowitz's message of "Tue, 5 Dec 2006 16:58:58 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00051.txt.bz2 Daniel Jacobowitz writes: > On Tue, Dec 05, 2006 at 04:56:39PM -0500, Daniel Jacobowitz wrote: >> I think we're being overly optimistic if we expect GCC to get it right >> all the time. In fact, I asked a bunch of GCC developers about it on >> IRC and the best response I got was "then you are screwed". Or Diego's >> explanation: >> >> > We don't explicitly try to handle it. it's mostly side-effect of >> > various optimizations. some times it's jump-threading, others it's >> > PRE, others it's CCP, others it's VRP. >> >> > that irritates the hell out of me. we depend on optimizations for >> > this warning. >> >> I know that's a widely held position. > > For the record, his followup makes that come out a bit differently: > >> I would love for someone to tackle this particular warning in >> an explicit and deterministic way. Solving it correctly is Turing-complete; I wonder what Diego had in mind. One alternative I've seen is Java's "definite assignment" rule: the language spec actually dictates a (not entirely dumb but not too hot either) flow analysis that is used to decide (if I remember right) whether you must initialize a varable or not. It's not The C Way to require initialization, but GCC could simply fix a particular algorithm for the sake of producing that warning.