From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22797 invoked by alias); 14 Mar 2002 19:46:16 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 22731 invoked by uid 71); 14 Mar 2002 19:46:09 -0000 Date: Thu, 14 Mar 2002 11:46:00 -0000 Message-ID: <20020314194609.22727.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Zack Weinberg Subject: Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4 Reply-To: Zack Weinberg X-SW-Source: 2002-03/txt/msg00479.txt.bz2 List-Id: The following reply was made to PR preprocessor/5806; it has been noted by GNATS. From: Zack Weinberg To: Neil Booth Cc: eric_dana@bmc.com, gcc-gnats@gcc.gnu.org, dick_schoeller@bmc.com Subject: Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4 Date: Thu, 14 Mar 2002 11:38:40 -0800 On Fri, Mar 01, 2002 at 11:13:14PM +0000, Neil Booth wrote: > Zack Weinberg wrote:- > > > The preprocessor ought to do this only in C99 mode; in C++ and > > presumably also C89 mode (I don't have a copy of C89 to check) it > > should use long/unsigned long, which may be 32 bits wide on some > > targets. Unfortunately, doing this properly requires substantial > > changes to GCC, which are planned, but not currently practical. > > (We're already not quite compliant; preprocessor arithmetic uses the > > _host's_ idea of intmax_t, not the target's.) > > > > Neil - as a stopgap, it occurs to me that we could mask intermediate > > values down to 32 bits when in C89/C++ mode and sizeof(target unsigned > > long) == 4. Thoughts? > > Sounds OK to me. Like you, I have the C++ and C99 standards, but no C89 > lying around. I do believe that the C++ preprocessor section was copied > almost verbatim (with some changes for bool and true / false) from C89 > though. I looked into this a little, and it founders on the usual problem: LONG_TYPE_SIZE can vary with target variables. So this is blocked on the integrated -E mode. We should make a serious effort to get that done for 3.2. zw