From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26245 invoked by alias); 14 Mar 2002 21:06:04 -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 26204 invoked by uid 71); 14 Mar 2002 21:06:03 -0000 Date: Thu, 14 Mar 2002 13:06:00 -0000 Message-ID: <20020314210603.26201.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "Dana, Eric" Subject: RE: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4 Reply-To: "Dana, Eric" X-SW-Source: 2002-03/txt/msg00481.txt.bz2 List-Id: The following reply was made to PR preprocessor/5806; it has been noted by GNATS. From: "Dana, Eric" To: "'Zack Weinberg'" , "'Neil Booth'" Cc: "Dana, Eric" , "'gcc-gnats@gcc.gnu.org'" , "Schoeller, Dick" Subject: RE: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4 Date: Thu, 14 Mar 2002 14:58:41 -0600 Zack, Is there anything that can be done for 3.1? In it's present state, Dynix cannot work properly as many of its include files test for 32/64 bit using the preprocessor. For example: #if ((~0UL) == 0xffffffffUL) typedef unsigned int size_t; /* ILP32 size_t */ #else /* ((~0UL) == 0xffffffffUL) */ typedef unsigned long size_t; /* LP64 size_t */ #endif /* ((~0UL) == 0xffffffffUL) */ The code between the #if #else #endif varies depending on the header file. For 3.1, could a modification in fixinc be made to handle the above mentioned type of case? Fixinc would know what the size of the HOST long is (can it determine the size of the TARGET long?). --Eric-- -----Original Message----- From: Zack Weinberg [mailto:zack@codesourcery.com] Sent: Thursday, March 14, 2002 2:39 PM 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 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