Re: [9fans] compiler bug

Re: [9fans] compiler bug

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 153 bytes --]

the compiler correctly marks it as unsigned int and uses the
correct shift operator and types in the resulting tree, but it goes wrong
a bit later.


[-- Attachment #2: Type: message/rfc822, Size: 2241 bytes --]

From: "Boyd Roberts" <boyd@fr.inter.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] compiler bug
Date: Thu, 12 Jul 2001 12:21:51 +0200
Message-ID: <063601c10abc$775b3500$c0b7c6d4@SOMA>

> In this case, 0x80000000 is not a representable value of type int,
> but is representable as unsigned int, so it should have that type.

eh?  it most certainly _can_ be represented as an int
if your machine has 32 bit ints.  all the world's a vax :)
until you hit the stupidity digital did with compiler
for the alpha.  int was always >= 16 bits and intended to
be the native machine 'word' size.

Re: [9fans] Compiler bug

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On 30 May 2014 14:03, Julius Schmidt <aiju@phicode.de> wrote:

> Comparing an int to a u16int causes the int to be cast to unsigned int,
> instead of the u16int being promoted to int and then compared (as I would
> argue the C89 standard specifies).


Ken's compiler implements the original unsigned-preserving rule instead of
ANSI's later invention.
That has the advantage of the type not being dependent on the underlying
storage size,
but as you say the disadvantage of not using the so-called value-preserving
rule.
I suppose if I add some code that detects where it made a difference it
might not cause too
much trouble to change from the simple rule. I imagine p9p has already
found most cases anyway.
Otherwise, it's another more subtler nsec!

[-- Attachment #2: Type: text/html, Size: 1245 bytes --]

[9fans] Compiler bug

[Julius Schmidt]

I have found what I believe to be a compiler bug: Comparing an int to a
u16int causes the int to be cast to unsigned int, instead of the u16int
being promoted to int and then compared (as I would argue the C89
standard specifies).
As a result -1 < u is false for any u16int u. Or is this intended behaviour?

I have verified that 8c exhibits the bug, but have not checked the other
compilers.
gcc does not seem to have this bug.

Julius Schmidt

Re: [9fans] compiler bug

[Mike Haertel]

>Does this still apply if a type has been explicitly requested with a
>suffix?  Eg, is the type of 0x100000000000L "long" because of the suffix,
>or "long long" because it won't fit in anything smaller?  (assuming 32
>bit longs).

That becomes a long long because it won't fit anything smaller.

Here is a table, laboriously typed in by hand from the standard
(with abbreviations courtesy of me being a lazy bum).  For those
who might care, the table comes from section 6.4.4.1, integer
constants, on page 56 of the C99 standard.

For each combination of suffix and type of constant, this
table it gives the sequence of types that will be tried to
fit the constant.


Suffix		Decimal Constant		Hex/Octal Constant
==================================================================
none		int, long, long long		int, u. int, long, u. long, long long, u. long long

U		u. int, u. long, u. long long	u. int, u. long, u. long long

L		long, long long			long, u. long, long long, u. long long

UL		u. long, u. long long		u. long, u. long long

ll		long long			long long, u. long long

ull		u. long long			u. long long


You can download a PDF of the C99 standard for $18 from ANSI at:
http://webstore.ansi.org/ansidocstore/product.asp?sku=ANSI%2FISO%2FIEC+9899%2D1999

	Mike

Re: [9fans] compiler bug

[David Gordon Hogan]

> prints -1.  It should print 1.  According to ANSI C (either version,
> take your pick: c89, section 3.1.3.2, or c99, section 6.4.4.1) hex
> and octal constants take on the first type in the list: int, unsigned
> int, long, unsigned long, etc. in which their value is representable.

Does this still apply if a type has been explicitly requested with a
suffix?  Eg, is the type of 0x100000000000L "long" because of the suffix,
or "long long" because it won't fit in anything smaller?  (assuming 32
bit longs).

This isn't an idle question, I've been looking at lex.c and thinking
about how best to make it "conformant".

(Time to get myself a copy of that standard, already!).

Re: [9fans] compiler bug

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]

i take it back. it goes wrong earlier than that, in lex.c
where it does mark it as ulong, but only after encouraging
convvtox to force it negative in the underlying vlong.


[-- Attachment #2: Type: message/rfc822, Size: 3968 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 153 bytes --]

the compiler correctly marks it as unsigned int and uses the
correct shift operator and types in the resulting tree, but it goes wrong
a bit later.


[-- Attachment #2.1.2: Type: message/rfc822, Size: 2241 bytes --]

From: "Boyd Roberts" <boyd@fr.inter.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] compiler bug
Date: Thu, 12 Jul 2001 12:21:51 +0200
Message-ID: <063601c10abc$775b3500$c0b7c6d4@SOMA>

> In this case, 0x80000000 is not a representable value of type int,
> but is representable as unsigned int, so it should have that type.

eh?  it most certainly _can_ be represented as an int
if your machine has 32 bit ints.  all the world's a vax :)
until you hit the stupidity digital did with compiler
for the alpha.  int was always >= 16 bits and intended to
be the native machine 'word' size.

Re: [9fans] compiler bug

[Boyd Roberts]

> In this case, 0x80000000 is not a representable value of type int,
> but is representable as unsigned int, so it should have that type.

eh?  it most certainly _can_ be represented as an int
if your machine has 32 bit ints.  all the world's a vax :)
until you hit the stupidity digital did with compiler
for the alpha.  int was always >= 16 bits and intended to
be the native machine 'word' size.

[9fans] compiler bug

[Mike Haertel]

Under pcc, the following program:

	#include <stdio.h>
	#include <stdlib.h>

	int
	main()
	{
		printf("%d\n", (int) (0x80000000 >> 31));
		exit(EXIT_SUCCESS);
	}

prints -1.  It should print 1.  According to ANSI C (either version,
take your pick: c89, section 3.1.3.2, or c99, section 6.4.4.1) hex
and octal constants take on the first type in the list: int, unsigned
int, long, unsigned long, etc. in which their value is representable.

In this case, 0x80000000 is not a representable value of type int,
but is representable as unsigned int, so it should have that type.

This bit me today when some of the initializers of an "unsigned long long"
array mysteriously got sign extended from 32 bits.