From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8379 invoked by alias); 27 Jul 2007 17:39:26 -0000 Received: (qmail 8370 invoked by uid 22791); 27 Jul 2007 17:39:25 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.177) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jul 2007 17:39:19 +0000 Received: by wa-out-1112.google.com with SMTP id m16so1001568waf for ; Fri, 27 Jul 2007 10:39:17 -0700 (PDT) Received: by 10.115.79.1 with SMTP id g1mr3163494wal.1185557957030; Fri, 27 Jul 2007 10:39:17 -0700 (PDT) Received: by 10.115.15.17 with HTTP; Fri, 27 Jul 2007 10:39:16 -0700 (PDT) Message-ID: <24b520d20707271039v5082931dp34abedc5122b58d3@mail.gmail.com> Date: Fri, 27 Jul 2007 18:03:00 -0000 From: "Doug Gregor" To: "Nathan Sidwell" Subject: Re: PING: C++0x decltype patch Cc: "GCC Patches" In-Reply-To: <46AA2AB7.5050004@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <24b520d20707251228m32ccd1bcs6af46b72c0598238@mail.gmail.com> <46A8EC73.80105@codesourcery.com> <24b520d20707270955u3e8aa8faw2eb52544ba7b3373@mail.gmail.com> <46AA2AB7.5050004@codesourcery.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-07/txt/msg02001.txt.bz2 On 7/27/07, Nathan Sidwell wrote: > Doug, > > The first sorry(), for BIT_FIELD_REF, should be a gcc_unreachable; it > > just can't happen here. The second "sorry" I'd like to keep... if we > > get here, it means that I somehow missed a particular member-access > > expression node. So, apologize to the user and when they report the > > bug, we'll see what the expression code is to fix the bug. Perhaps > > internal_error would be better? > > IMHO that's exactly what > gcc_assert (TYPE_P (expr) || DECL_P (expr)) > is for :) sorry is for pieces we _know_ we've not implemented. Here we _think_ > we've covered all the cases, so an assert is appropriate. Understood. I'll turn it into an assert. - Doug