RE: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

RE: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[Dana, Eric]

The following reply was made to PR preprocessor/5806; it has been noted by GNATS.

From: "Dana, Eric" <Eric_Dana@bmc.com>
To: "'Zack Weinberg'" <zack@codesourcery.com>,
   "Dana, Eric"
	 <Eric_Dana@bmc.com>
Cc: "'Neil Booth'" <neil@daikokuya.demon.co.uk>,
   "'gcc-gnats@gcc.gnu.org'"
	 <gcc-gnats@gcc.gnu.org>,
   "Schoeller, Dick" <Dick_Schoeller@bmc.com>
Subject: RE: preprocessor/5806: The preprocessor evaluates expression s in
	 64-bit, violating IS C++ 16.1.4
Date: Mon, 5 Aug 2002 17:24:15 -0500 

 Zack,
 
    Although the changes are on the mainline, they aren't implemented for
    Gcc 3.2.x. The suggestion below does work, but I made the changes to the
    .h files using a sed script (I wasn't able to get this patch working with
    fix includes stuff). If the fix includes (on the 3.2.x branch) can be
    made to make the suggested changes then sequent should be supported.
 
 --Eric--
 
 -----Original Message-----
 From: 'Zack Weinberg' [mailto:zack@codesourcery.com] 
 Sent: Saturday, August 03, 2002 3:53 AM
 To: Dana, Eric
 Cc: 'Neil Booth'; '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
 
 On Fri, Mar 15, 2002 at 10:37:47AM -0600, Dana, Eric wrote:
 > Zack,
 > 
 >    The config.guess output is: i386-sequent-sysv4
 >    One possibility is to change the '#if ((~0UL) == 0xffffffffUL)' to
 >    '#if defined(__i386__)' which is predefined in the gcc compiler.
 >    You may have a better suggestion... Tnx...
 
 I believe this has been resolved in the mainline sources; can you
 check to see whether the problem still persists?
 
 Thanks,
 zw

Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

['Zack Weinberg']

The following reply was made to PR preprocessor/5806; it has been noted by GNATS.

From: 'Zack Weinberg' <zack@codesourcery.com>
To: "Dana, Eric" <Eric_Dana@bmc.com>
Cc: 'Neil Booth' <neil@daikokuya.demon.co.uk>,
	"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>,
	"Schoeller, Dick" <Dick_Schoeller@bmc.com>
Subject: Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4
Date: Sat, 3 Aug 2002 00:52:37 -0700

 On Fri, Mar 15, 2002 at 10:37:47AM -0600, Dana, Eric wrote:
 > Zack,
 > 
 >    The config.guess output is: i386-sequent-sysv4
 >    One possibility is to change the '#if ((~0UL) == 0xffffffffUL)' to
 >    '#if defined(__i386__)' which is predefined in the gcc compiler.
 >    You may have a better suggestion... Tnx...
 
 I believe this has been resolved in the mainline sources; can you
 check to see whether the problem still persists?
 
 Thanks,
 zw

Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[neil]

Synopsis: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

State-Changed-From-To: analyzed->closed
State-Changed-By: neil
State-Changed-When: Mon May 27 12:22:20 2002
State-Changed-Why:
    After some recent patches of mine, GCC 3.2 does preprocessor arithmetic to the precision of the target's intmax_t, as required by the C99 standard.
    
    As you can see from a discussion in the last two days on GCC-patches mailing list, it was decided that we should do this in C89 mode as well, otherwise there is no consistent way for us to have the long-long extension.
    
    Now, you claim it violates the ISO C++ and C89 standards.  In fact it does not; if you read the relevant section carefully, it says that CPP arithmetic is done to *at least* the precision of the target "long" type.  By using intmax_t, we are in compliance with this requirement:
    
    "... the controlling constant expression ... is evaluated according to the rules of 6.4 using arithmetic that has *at least* the ranges specified in 5.2.4.2, except that int and unsigned int act as if they have the same representation as, respectively, long and unsigned long."
    
    Because of this wording, any code that relied on the C89 preprocessor to determine properties of the target machine precision was always broken.
    
    Thanks for the bug report.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5806

Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[neil]

Synopsis: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

Responsible-Changed-From-To: unassigned->neil
Responsible-Changed-By: neil
Responsible-Changed-When: Sun May 26 11:32:34 2002
Responsible-Changed-Why:
    Mine.  I'm working on CPP arithmetic precision.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5806

Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[neil]

Synopsis: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

State-Changed-From-To: open->analyzed
State-Changed-By: neil
State-Changed-When: Mon Mar 25 00:53:41 2002
State-Changed-Why:
    Confrimed; we hope to fix this for GCC 3.2.  Please don't use priority high when submitting bug reports.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5806

RE: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[Dana, Eric]

The following reply was made to PR preprocessor/5806; it has been noted by GNATS.

From: "Dana, Eric" <Eric_Dana@bmc.com>
To: "'Zack Weinberg'" <zack@codesourcery.com>,
   "Dana, Eric"
	 <Eric_Dana@bmc.com>
Cc: "'Neil Booth'" <neil@daikokuya.demon.co.uk>,
   "'gcc-gnats@gcc.gnu.org'"
	 <gcc-gnats@gcc.gnu.org>,
   "Schoeller, Dick" <Dick_Schoeller@bmc.com>
Subject: RE: preprocessor/5806: The preprocessor evaluates expression s in
	 64-bit, violating IS C++ 16.1.4
Date: Fri, 15 Mar 2002 10:37:47 -0600

 Zack,
 
    The config.guess output is: i386-sequent-sysv4
    One possibility is to change the '#if ((~0UL) == 0xffffffffUL)' to
    '#if defined(__i386__)' which is predefined in the gcc compiler.
    You may have a better suggestion... Tnx...
 
 --Eric--
 
 -----Original Message-----
 From: 'Zack Weinberg' [mailto:zack@codesourcery.com] 
 Sent: Thursday, March 14, 2002 6:15 PM
 To: Dana, Eric
 Cc: 'Neil Booth'; '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
 
 
 On Thu, Mar 14, 2002 at 02:58:41PM -0600, Dana, Eric wrote:
 > 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) */
 
 In the short term, a fixincludes hack is probably the right move.  GCC
 almost certainly provides a predefined macro that you can use to
 detect the mode you're in -- tell me the output of config.guess and I
 can figure out what it should be.  Then you have fixincludes look for
 that #if and change it to an appropriate test of the macro.
 
 zw

Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

['Zack Weinberg']

The following reply was made to PR preprocessor/5806; it has been noted by GNATS.

From: 'Zack Weinberg' <zack@codesourcery.com>
To: "Dana, Eric" <Eric_Dana@bmc.com>
Cc: 'Neil Booth' <neil@daikokuya.demon.co.uk>,
	"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>,
	"Schoeller, Dick" <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 15:14:39 -0800

 On Thu, Mar 14, 2002 at 02:58:41PM -0600, Dana, Eric wrote:
 > 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) */
 
 In the short term, a fixincludes hack is probably the right move.  GCC
 almost certainly provides a predefined macro that you can use to
 detect the mode you're in -- tell me the output of config.guess and I
 can figure out what it should be.  Then you have fixincludes look for
 that #if and change it to an appropriate test of the macro.
 
 zw

Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

['Neil Booth']

The following reply was made to PR preprocessor/5806; it has been noted by GNATS.

From: 'Neil Booth' <neil@daikokuya.demon.co.uk>
To: "Dana, Eric" <Eric_Dana@bmc.com>
Cc: 'Zack Weinberg' <zack@codesourcery.com>,
	"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>,
	"Schoeller, Dick" <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 21:01:59 +0000

 Dana, Eric wrote:-
 
 >    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:
 
 This is a broken test, so there is little point fixing GCC for this
 purpose.
 
 > 	#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) */
 
 Neil.

RE: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[Dana, Eric]

The following reply was made to PR preprocessor/5806; it has been noted by GNATS.

From: "Dana, Eric" <Eric_Dana@bmc.com>
To: "'Zack Weinberg'" <zack@codesourcery.com>,
   "'Neil Booth'"
	 <neil@daikokuya.demon.co.uk>
Cc: "Dana, Eric" <Eric_Dana@bmc.com>,
   "'gcc-gnats@gcc.gnu.org'"
	 <gcc-gnats@gcc.gnu.org>,
   "Schoeller, Dick" <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 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

Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[Zack Weinberg]

The following reply was made to PR preprocessor/5806; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
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

Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[Neil Booth]

The following reply was made to PR preprocessor/5806; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: Zack Weinberg <zack@codesourcery.com>
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: Fri, 1 Mar 2002 23:13:14 +0000

 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.
 
 Neil.

Re: preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[Zack Weinberg]

The following reply was made to PR preprocessor/5806; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: eric_dana@bmc.com
Cc: gcc-gnats@gcc.gnu.org, dick_schoeller@bmc.com,
	Neil Booth <neil@daikokuya.demon.co.uk>
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 <stdint.h>.
 
 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
 

preprocessor/5806: The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4

[eric_dana]

>Number:         5806
>Category:       preprocessor
>Synopsis:       The preprocessor evaluates expression s in 64-bit, violating IS C++ 16.1.4
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 01 12:16:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Eric Dana
>Release:        GCC 3.0.4 and possibly GCC 3.1
>Organization:
>Environment:
AIX, Solaris, Sequent and others
>Description:
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.

The vendor compilers work according to the standard.

>How-To-Repeat:
On Solaris (64-bit):
cc ed.c
a.out
cc -xarch=v9 ed.c   (64-bit build)
a.out
gcc ed.c
a.out

On all OS's:
cc ed.c
a.out
gcc ed.c
a.out

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/plain; name="ed.c"
Content-Disposition: inline; filename="ed.c"

#if 0
#if ((~0UL) == (0xffffffffUL))
#define MYSIZESTRING "32 bit"
#else
#define MYSIZESTRING "64 bit"
#endif
#endif
#define MYSIZESTRING "foo"
#include <stdio.h>

main ()
{
  printf("sizeof long = %d\n", sizeof(long));
  printf("C preprocessor thinks the size is: %s\n", MYSIZESTRING);
}