From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14999 invoked by alias); 1 Mar 2002 21:36:01 -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 14959 invoked by uid 71); 1 Mar 2002 21:36:01 -0000 Date: Fri, 01 Mar 2002 13:36:00 -0000 Message-ID: <20020301213601.14953.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/msg00013.txt.bz2 List-Id: The following reply was made to PR preprocessor/5806; it has been noted by GNATS. From: Zack Weinberg To: eric_dana@bmc.com Cc: gcc-gnats@gcc.gnu.org, dick_schoeller@bmc.com, Neil Booth Subject: Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4 Date: Fri, 1 Mar 2002 13:26:51 -0800 > The preprocessor evaluates expressions using 64-bits, violating ISO > C++ 16.1.4 and 5.19. The problems is generic and can be easily > reproduced. This causes the 32/64 bit test on Sequent provided > header files to be incorrectly parsed. Yes, you're right. The preprocessor is obeying ISO C99 6.10.1p3: ... all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header . You can see that this is substantially the same as C++ 16.1p4 [cpp.cond] except that intmax_t and uintmax_t have been substituted for long and unsigned long. The former are required to be at least 64 bits wide. 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? zw