From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8869 invoked by alias); 1 Oct 2002 19:03:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8858 invoked from network); 1 Oct 2002 19:03:25 -0000 Received: from unknown (HELO desire.geoffk.org) (12.235.56.190) by sources.redhat.com with SMTP; 1 Oct 2002 19:03:25 -0000 Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id g91J1GY02988; Tue, 1 Oct 2002 12:01:16 -0700 X-Authentication-Warning: desire.geoffk.org: geoffk set sender to geoffk@geoffk.org using -f To: Joe Buck Cc: bkorb@pacbell.net (Bruce Korb), dewar@gnat.com (Robert Dewar), zack@codesourcery.com, gcc@gcc.gnu.org Subject: Re: module level flags References: <200210011827.LAA11402@atrus.synopsys.com> From: Geoff Keating Date: Tue, 01 Oct 2002 12:16:00 -0000 In-Reply-To: <200210011827.LAA11402@atrus.synopsys.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg00044.txt.bz2 Joe Buck writes: > There is an argument for attempting to detect obvious cases of error, and > this would help users. Some developers have objected that because not all > errors can be detected, this would give users a false sense of security > when they don't see any aliasing warnings. No-one has objected to someone adding a flag that detects certain "obvious" cases of violating the aliasing rules. At least one patch was posted in 1999 by Zack, but it never quite worked well enough to go in the tree. In fact, I believe there was some consensus that it's even OK to warn about such constructs as: double *dp; int *ip = (int *)dp; even though that's not an immediate problem, since it is at least very suspicious. The flag would not be on by default, of course. Amusingly, it used to be that GCC had lots of constructs like that, but I think I've cleaned up many of them as part of the new GC work. I think that generally, such warnings are helpful even if they aren't 100% perfect. The usual reason such errors are introduced into programs are not that the programmer made a mistake in applying the appropriate rule, it's that the programmer wasn't aware that the rule existed. Thus, the warnings help to educate programmers, and hopefully they will be educated enough that they don't make the mistakes that the compiler can't catch. -- - Geoffrey Keating