This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: preprocessor bug in gcc 2.95.2[.1]
- To: meow at pobox dot com
- Subject: Re: preprocessor bug in gcc 2.95.2[.1]
- From: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Date: Thu, 8 Mar 2001 07:38:33 +0000
- Cc: gcc-bugs at gcc dot gnu dot org, lpm at us dot ibm dot com, lpm at pobox dot com
- References: <000201c0a7a0$04298610$13afe220@wlpm>
Laurent Montaron wrote:-
> Interesting problem seen on on Intel 32-bit platforms such as cygwin32
> or i386-*-svr4 with GCC 2.95.2 and 2.95.2.1 .
>
> The preprocessor evaluates the expression "(~0UL) == (0xFFFFFFFFUL)" as
> false, whereas it is true on IA-32, where "unsigned long int" is a
> 32-bit quantity.
Preprocessor arithmetic on Intel is done in 64-bits, which is correct.
Roughly, I think for most processors it is done in integers with double
the width of the widest native type. The correct type for the new standard
is int_max_t, which is long long in your case.
Neil.
> #if ((~0UL) == 0xffffffffUL)
> typedef unsigned int size_t; /* ILP32 size_t */
> #else
> typedef unsigned long size_t; /* LP64 size_t */
> #endif /* ((~0UL) == 0xffffffffUL) */
>
> Amusingly, the GNU preprocessor evaluates "(~0UL) == (0xFFFFFFFFFFFFFFFFUL)"
> as true, which doesn't make much sense to me.
See above.