From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14546 invoked by alias); 24 Oct 2002 07:36:03 -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 14539 invoked from network); 24 Oct 2002 07:36:02 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 24 Oct 2002 07:36:02 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g9O7Xag02379; Thu, 24 Oct 2002 00:33:36 -0700 Date: Thu, 24 Oct 2002 09:17:00 -0000 From: Mark Mitchell To: David Edelsohn , Joe Buck cc: "gcc@gcc.gnu.org" Subject: Re: Update: status of high-priority GNATS bugs Message-ID: <23080000.1035444816@warlock.codesourcery.com> In-Reply-To: <200210231705.NAA24234@makai.watson.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-10/txt/msg01478.txt.bz2 --On Wednesday, October 23, 2002 01:05:44 PM -0400 David Edelsohn wrote: >>>>>> Joe Buck writes: > > Joe> Sigh, so much for my theory ... in my brief gdb debug session the > Joe> infinite loop looked the same. > > I think they *are* similar. I am trying to poke at the problem, > but parsers and G++'s parser are not my expertise. It may simply be that > Mark was too conservative in his patch for the other PR, like limiting it > to blev==0 (brace level). They were related. My second patch would have caused the first test case not to loop forever -- but G++ would still have issued a spurious error. The first patch made sure that we identified the start and end of the inline function correctly; the second patch made sure that an error in an inline function doesn't cause us to loop forever. As you say, G++ has made great strides towards conformance, and a lot of the regressions we are fixing now are truly corner-cases, albeit corner-cases people have found in real code. The most important thing about the new parser is, in a way, not that it will be more conformant (it will be), but that it will allow us to considerably tighten the interfaces throughout the front end. We have a ton of code to compensate for what our parser cannot do; once we have a parser that gets it right we can get rid of all that, and make things a lot more transparent. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com