From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12435 invoked by alias); 16 Mar 2010 01:28:58 -0000 Received: (qmail 12422 invoked by uid 22791); 16 Mar 2010 01:28:57 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail-bw0-f224.google.com (HELO mail-bw0-f224.google.com) (209.85.218.224) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Mar 2010 01:28:53 +0000 Received: by bwz24 with SMTP id 24so3785876bwz.16 for ; Mon, 15 Mar 2010 18:28:51 -0700 (PDT) Received: by 10.204.145.23 with SMTP id b23mr3440011bkv.17.1268702931205; Mon, 15 Mar 2010 18:28:51 -0700 (PDT) Received: from [192.168.2.99] (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id s17sm23572693bkd.16.2010.03.15.18.28.48 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 18:28:49 -0700 (PDT) Message-ID: <4B9EE319.5080204@gmail.com> Date: Tue, 16 Mar 2010 01:32:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Sean D'Epagnier CC: gcc@gcc.gnu.org Subject: Re: fixed-point support in c++ References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-03/txt/msg00163.txt.bz2 On 15/03/2010 22:03, Sean D'Epagnier wrote: > - { "_Fract", RID_FRACT, D_CONLY | D_EXT }, > - { "_Accum", RID_ACCUM, D_CONLY | D_EXT }, > - { "_Sat", RID_SAT, D_CONLY | D_EXT }, > + { "_Fract", RID_FRACT, D_EXT }, > + { "_Accum", RID_ACCUM, D_EXT }, > + { "_Sat", RID_SAT, D_EXT }, > Now the error is: > > test.cpp:5:4: error: expected primary-expression before ‘_Accum’ > > Does anyone have clues as to the problem? The problem is that it won't be as simple as that. You'll have to extend the C++ parser to accept those new RID_ values that it was previously never expecting to see in those contexts, I would think (but haven't verified against the source yet). The C++ parser is a hand-coded recursive-descent parser, so I wouldn't expect it to be generically able to deal with previously-unknown token types suddenly appearing in its input stream at arbitrary points. cheers, DaveK