From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-158645-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 16338 invoked by alias); 15 Dec 2009 00:38:31 -0000
Received: (qmail 16325 invoked by uid 22791); 15 Dec 2009 00:38:31 -0000
X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 	tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail-svr1.cs.utah.edu (HELO mail-svr1.cs.utah.edu) (155.98.64.241)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Dec 2009 00:38:24 +0000
Received: from mail-svr1.cs.utah.edu (localhost [127.0.0.1]) 	by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 9DEB46500AF; 	Mon, 14 Dec 2009 17:38:22 -0700 (MST)
Received: from thebes.cs.utah.edu (thebes.cs.utah.edu [155.98.65.57]) 	by mail-svr1.cs.utah.edu (Postfix) with ESMTP; 	Mon, 14 Dec 2009 17:38:22 -0700 (MST)
Date: Tue, 15 Dec 2009 00:38:00 -0000
From: John Regehr <regehr@cs.utah.edu>
To: Joe Buck <Joe.Buck@synopsys.COM>
cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: detailed comparison of generated code size for GCC and other  compilers
In-Reply-To: <20091214220612.GG7973@synopsys.com>
Message-ID: <alpine.DEB.1.00.0912141736190.19671@thebes.cs.utah.edu>
References: <4B265B23.1010102@cs.utah.edu> <87hbrty1k5.fsf@basil.nowhere.org> <alpine.DEB.1.00.0912140920200.10900@thebes.cs.utah.edu> <20091214171745.GD16474@basil.fritz.box> <20091214174614.GA12422@caradoc.them.org> <alpine.DEB.1.00.0912141332390.15274@thebes.cs.utah.edu>  <20091214214628.GF7973@synopsys.com> <alpine.DEB.1.00.0912141451280.12585@babel.cs.utah.edu> <20091214220612.GG7973@synopsys.com>
User-Agent: Alpine 1.00 (DEB 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-IsSubscribed: yes
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2009-12/txt/msg00198.txt.bz2

> I would only be worried for cases where no warning is issued *and*
> unitialized accesses are eliminated.

Yeah, it would be excellent if GCC maintained the invariant that for all 
uses of uninitialized storage, either the compiler or else valgrind will 
issue a warning.

We could test for violations of this.  Several times I've thought about 
cross-testing various compilers and versions of compilers for consistency 
of warnings.  But I never managed to convince myself that developers would 
care enough to make it worth the trouble.

John