From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17138 invoked by alias); 5 Jan 2007 14:20:13 -0000 Received: (qmail 17089 invoked by uid 22791); 5 Jan 2007 14:20:12 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.168) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 05 Jan 2007 14:20:06 +0000 Received: by ug-out-1314.google.com with SMTP id s2so5627936uge for ; Fri, 05 Jan 2007 06:20:03 -0800 (PST) Received: by 10.82.136.4 with SMTP id j4mr1598096bud.1168006803786; Fri, 05 Jan 2007 06:20:03 -0800 (PST) Received: by 10.82.150.13 with HTTP; Fri, 5 Jan 2007 06:20:03 -0800 (PST) Message-ID: <84fc9c000701050620v647343e2n30074cd15d47f02b@mail.gmail.com> Date: Fri, 05 Jan 2007 14:20:00 -0000 From: "Richard Guenther" To: "Doug Gregor" Subject: Re: [PATCH, C++] Make Canonical ICE instead of just warn when mismatching Cc: "Brooks Moses" , gcc-patches@gcc.gnu.org In-Reply-To: <24b520d20701050613h10bddaceu567ee42e6b4e111f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <459DC221.4030201@codesourcery.com> <24b520d20701050613h10bddaceu567ee42e6b4e111f@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-01/txt/msg00385.txt.bz2 On 1/5/07, Doug Gregor wrote: > On 1/4/07, Brooks Moses wrote: > > My impression from your argument is that this case is not like that; > > that here we know that a failure to pass this particular internal check > > will never result in invalid code. And thus a warning is appropriate > > here, because the user will still get valid usable code if they ignore > > the warning. > > > > Is this a correct impression? I haven't seen any mention of this > > distinction, but it seems to me that it's the only way that the argument > > for a warning instead of a hard error would make sense. > > Yes, your impression is correct. > > The canonical types implementation is a compile-time optimization that > makes comparing types for equality (e.g., is "int*" the same as > "my_int_t*"?) faster. Previously, we would have to look at the > structure of the types to determine if they are equivalent; with > canonical types, we only do a single pointer comparison. However, the > code that looks at the structure of types is still needed for some > comparisons, so it's still available for us to use when checking. > > As it stands now, there is a parameter "verify-canonical-types". When > it is zero (the default for --disable-checking builds), we trust the > canonical type system to be correct and get our 5-10% speedup on > template-heavy code. When it is one (the default for --enable-checking > builds), we compare the results of the older, slower structure-based > comparison against the results of the canonical type comparison. If > they differ, we complain. Then, we can recover from the failure of the > canonical-types system by reporting the result that the > structure-based comparison determined. So for --disable-checking builds we can get the wrong answer for T1 == T2 and so generate wrong code? In this case the error should be fatal, so we get each error reported and not get silent failures at the time 4.3 is released. Richard.