Re: [9fans] Is this a bug in 8c?

Re: [9fans] Is this a bug in 8c?

[forsyth]

>>Wow, the snide self-superiority of the previous conversation is really
>>coming home to roost.

i don't think anyone was snide, or even self-superior.
we just don't think gcc is the alpha and omega of compilers,
or even that the trade-offs make sense everywhere.

give it a rest.

Re: [9fans] Is this a bug in 8c?

[Thomas Bushnell, BSG]

forsyth@caldo.demon.co.uk writes:

> >>Wow, the snide self-superiority of the previous conversation is really
> >>coming home to roost.
> 
> i don't think anyone was snide, or even self-superior.
> we just don't think gcc is the alpha and omega of compilers,
> or even that the trade-offs make sense everywhere.

The argument was that GCC is bloated and bugridden and unreliable,
where 8c is fast, lean, and (as a consequence), bug free.

And it turns out that 8c has plenty of *intentional* bugs. 

The claim was that GCC trades optimization for correctness, when it
certainly makes no such intentional trade.

But 8c in fact *does* make such trades, either to save developer time,
or just a deliberate "yes, this is wrong, but the generated code is
faster!"

Thomas

Re: [9fans] Is this a bug in 8c?

[William Josephson]

On Fri, Mar 15, 2002 at 04:53:15PM +0000, Thomas Bushnell, BSG wrote:

> The claim was that GCC trades optimization for correctness, when it
> certainly makes no such intentional trade.

Intention doesn't have much to do with it as far as I can tell.

> But 8c in fact *does* make such trades, either to save developer time,
> or just a deliberate "yes, this is wrong, but the generated code is
> faster!"

> Thomas

You're a really sore loser, you know that?

Re: [9fans] Is this a bug in 8c?

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

> a) long long is not an integer type according to the ANSI C standard I
> hold in my hand.  Perhaps it is in C9X, but it's not even mentioned in
> the old standard.  It isn't a type at all as far as the standard is
> concerned.  I know other compilers came to implement it, but where in
> the 1989 standard - the one 8c was written to - does it mention long
> long?

It's not a standards violation, but it's clear that it's a bug.

> b) 8c is not "riddled" with "intentional bugs".  Be careful who you
> call snide and self-superior.  I think the strongest honest statement
> you could make as far as long long is concerned is that some of the
> operations on the long long extension are unimplemented.  That is a
> far cry from "riddled" with "intentional bugs".

Even the error message was improper, since it didn't say anything
about what the actual problem was.  Make that four bugs now.

Re: [9fans] Is this a bug in 8c?

[Fco.J.Ballesteros]

Now that bwc points out what I was thinking about,
Could we agree to stop sending childish messages or to
create a 9rant mailing list for them (like it was done for the
licensing issues)?

sorry to increase the noise portion of the list.

Re: [9fans] Is this a bug in 8c?

[bwc]

As the one who made the first posting, I want to express my distaste
for what just happened.  I posted something I saw that seemed odd.
This is what this list is for.  I got a quick response that made complete
sense.  It would be very childish of me to not be thankful for long long
JUST THE WAY IT CURRENTLY IS.  It's useful, even if it's not fully integrated
into the language.

The hateful response to the answer may demonstrate the effects
using emacs has on the brain.  Is there not enough traffic on the
GNU lists?

  Brantley

Re: [9fans] Is this a bug in 8c?

[Russ Cox]

> Are there more of these cute litlle intentional bugs? 

All the gcc extensions are unimplemented.

Plonk.

Re: [9fans] Is this a bug in 8c?

[Russ Cox]

> > 8c et al. don't do ? : for non-integer types,
> > and long long is a non-integer type (meaning
> > it's synthesized from multiple machine words).
> 
> long long is an "integer type" according to the meaning
> of that term in the C standard.  That's not determined
> by implementation details such as how many words are needed.

x g/> >/ s/integer/register/.  happy?

i gave a precise description of what was and was not
implemented.  i was not trying to justify it by an
appeal to language law.

Re: [9fans] Is this a bug in 8c?

[rob pike]

> long long is an "integer type" according to the meaning
> of that term in the C standard. 
....
> ... snide self-superiority ...
> 8c is apparently
> riddled with *intentional* bugs. 

Just a minute here.  I'm not apologizing for long long not supporting
?:, because I think it really should, but nonetheless:

a) long long is not an integer type according to the ANSI C standard I
hold in my hand.  Perhaps it is in C9X, but it's not even mentioned in
the old standard.  It isn't a type at all as far as the standard is
concerned.  I know other compilers came to implement it, but where in
the 1989 standard - the one 8c was written to - does it mention long
long?

b) 8c is not "riddled" with "intentional bugs".  Be careful who you
call snide and self-superior.  I think the strongest honest statement
you could make as far as long long is concerned is that some of the
operations on the long long extension are unimplemented.  That is a
far cry from "riddled" with "intentional bugs".

-rob

Re: [9fans] Is this a bug in 8c?

[forsyth]

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

it probably boils down to ``nothing in the system needs it that much (yet)'',
and there were plenty of other worthwhile things to do (such as storing the hits of the 60s),
but since offsets are now 64 bits, it's probable that something will be done about it.
the long long support was originally light, but has changed over the past year or so.

>>Strange, it's about the same as supporting "long" on the PDP-11.

it took a little while for that to be done fully, too.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Is this a bug in 8c?
Date: Fri, 15 Mar 2002 10:19:07 GMT
Message-ID: <3C914F6C.D2F42C9E@null.net>

Russ Cox wrote:
> 8c et al. don't do ? : for non-integer types,
> and long long is a non-integer type (meaning
> it's synthesized from multiple machine words).

long long is an "integer type" according to the meaning
of that term in the C standard.  That's not determined
by implementation details such as how many words are needed.

> Ken said the amount of work wasn't worth it.

Strange, it's about the same as supporting "long" on the PDP-11.

Re: [9fans] Is this a bug in 8c?

[Douglas A. Gwyn]

Russ Cox wrote:
> 8c et al. don't do ? : for non-integer types,
> and long long is a non-integer type (meaning
> it's synthesized from multiple machine words).

long long is an "integer type" according to the meaning
of that term in the C standard.  That's not determined
by implementation details such as how many words are needed.

> Ken said the amount of work wasn't worth it.

Strange, it's about the same as supporting "long" on the PDP-11.

Re: [9fans] Is this a bug in 8c?

[Thomas Bushnell, BSG]

rsc@plan9.bell-labs.com (Russ Cox) writes:

> 8c et al. don't do ? : for non-integer types,
> and long long is a non-integer type (meaning
> it's synthesized from multiple machine words).
> Ken said the amount of work wasn't worth it.

Wow, the snide self-superiority of the previous conversation is really
coming home to roost.

GCC is castigated for having "too many bugs", while 8c is apparently
riddled with *intentional* bugs.  So far we have the
aliasing/registerization bug in optimization, that long long is not
treated as an integer type, and that ?: doesn't work for non-integer
types.

Are there more of these cute litlle intentional bugs? 

Thomas

Re: [9fans] Is this a bug in 8c?

[Martin Harriss]

Russ Cox wrote:
> 
> 8c et al. don't do ? : for non-integer types,
> and long long is a non-integer type (meaning
> it's synthesized from multiple machine words).
> Ken said the amount of work wasn't worth it.
> 
> Russ

But it doesn't do the comma operator for long longs either.  I found
that quite annoying when trying to port something to Plan 9.  Surely
that would not be so hard?

In any event, I agree that the error message makes it look like there's
a bug.

Martin

Re: [9fans] Is this a bug in 8c?

[Russ Cox]

8c et al. don't do ? : for non-integer types,
and long long is a non-integer type (meaning
it's synthesized from multiple machine words).
Ken said the amount of work wasn't worth it.

Russ

[9fans] Is this a bug in 8c?

[bwc]

Is there a bug in 8c compiling the following?

main(void) {
	long long a, b, c, d;

	getval(&a, &b, &c, &d);
	a = b + c > d ? d - b : c;
}

gives

/usr/bwc/bug.c:4 function args not checked: getval
/usr/bwc/bug.c:5 unknown vlong LIST
/usr/bwc/bug.c:5 unknown vlong COND
8c 6915:error