9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] remember when C compiler used to produce working code? i don't!
@ 2004-01-30 22:05 andrey mirtchovski
  2004-01-30 22:29 ` David Presotto
  0 siblings, 1 reply; 17+ messages in thread
From: andrey mirtchovski @ 2004-01-30 22:05 UTC (permalink / raw)
  To: 9fans

I got bitten by this one pretty hard today, took me the better part of
the day to find out...  The 'elasticity *= ratio' code comes from the
XScreensaver distribution and was written sometime in 1997, so
presumably this has been working since then (and braking when compiled
with 8c?).

In Plan 9 the following code produces 800/0:

	plan9-2% cat t.c
	#include <u.h>
	#include <libc.h>

	main()
	{
		long elasticity = 8000L;
		double ratio = 0.1;

		/* this is fine */
		elasticity = (long)(((double)elasticity)*ratio);
		print("%ld\n", elasticity);

		/* this breaks with 8c */
		elasticity *= ratio;
		print("%ld\n", elasticity);

	}
	plan9-2% 8c t.c; 8l t.8
	plan9-2% 8.out
	800
	0
	plan9-2%


Its (almost) identical lunix counterpart, when compiled with gcc 3.2,
produces 800/80:

	mirtchov@fbsd$ cat t.c
	main()
	{
	        long elasticity = 8000L;
	        double ratio = 0.1;

		/* this is fine */
	        elasticity = (long)(((float)elasticity)*ratio);
	        printf("%ld\n", elasticity);

		/* this if fine with gcc 3.2 */
	        elasticity *= ratio;
	        printf("%ld\n", elasticity);

	}
	mirtchov@fbsd$ gcc t.c
	mirtchov@fbsd$ ./a.out
	800
	80
	mirtchov@fbsd$


Not looking to assign any blame, just letting you know...

andrey



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-30 22:05 [9fans] remember when C compiler used to produce working code? i don't! andrey mirtchovski
@ 2004-01-30 22:29 ` David Presotto
  2004-01-30 22:40   ` David Presotto
  0 siblings, 1 reply; 17+ messages in thread
From: David Presotto @ 2004-01-30 22:29 UTC (permalink / raw)
  To: 9fans

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

It does work if you replace:

	        elasticity *= ratio;

with

	        elasticity = elasticity * ratio;

Clearly we're analyzing wrong when there's only an assignment.

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

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: [9fans] remember when C compiler used to produce working code? i don't!
Date: Fri, 30 Jan 2004 15:05:43 -0700
Message-ID: <d45fb131231fd5a3515e0f7518a6568a@plan9.ucalgary.ca>

I got bitten by this one pretty hard today, took me the better part of
the day to find out...  The 'elasticity *= ratio' code comes from the
XScreensaver distribution and was written sometime in 1997, so
presumably this has been working since then (and braking when compiled
with 8c?).

In Plan 9 the following code produces 800/0:

	plan9-2% cat t.c
	#include <u.h>
	#include <libc.h>

	main()
	{
		long elasticity = 8000L;
		double ratio = 0.1;

		/* this is fine */
		elasticity = (long)(((double)elasticity)*ratio);
		print("%ld\n", elasticity);

		/* this breaks with 8c */
		elasticity *= ratio;
		print("%ld\n", elasticity);

	}
	plan9-2% 8c t.c; 8l t.8
	plan9-2% 8.out
	800
	0
	plan9-2%


Its (almost) identical lunix counterpart, when compiled with gcc 3.2,
produces 800/80:

	mirtchov@fbsd$ cat t.c
	main()
	{
	        long elasticity = 8000L;
	        double ratio = 0.1;

		/* this is fine */
	        elasticity = (long)(((float)elasticity)*ratio);
	        printf("%ld\n", elasticity);

		/* this if fine with gcc 3.2 */
	        elasticity *= ratio;
	        printf("%ld\n", elasticity);

	}
	mirtchov@fbsd$ gcc t.c
	mirtchov@fbsd$ ./a.out
	800
	80
	mirtchov@fbsd$


Not looking to assign any blame, just letting you know...

andrey

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-30 22:29 ` David Presotto
@ 2004-01-30 22:40   ` David Presotto
  2004-01-31  0:57     ` Bruce Ellis
  0 siblings, 1 reply; 17+ messages in thread
From: David Presotto @ 2004-01-30 22:40 UTC (permalink / raw)
  To: 9fans

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

Looks like a problem in cc/com.c in tcomo().  I'm going to be away
for a week and will take a crack at it when I get back.  If someone
else wants to try in the mean time...

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

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

It does work if you replace:

	        elasticity *= ratio;

with

	        elasticity = elasticity * ratio;

Clearly we're analyzing wrong when there's only an assignment.

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

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: [9fans] remember when C compiler used to produce working code? i don't!
Date: Fri, 30 Jan 2004 15:05:43 -0700
Message-ID: <d45fb131231fd5a3515e0f7518a6568a@plan9.ucalgary.ca>

I got bitten by this one pretty hard today, took me the better part of
the day to find out...  The 'elasticity *= ratio' code comes from the
XScreensaver distribution and was written sometime in 1997, so
presumably this has been working since then (and braking when compiled
with 8c?).

In Plan 9 the following code produces 800/0:

	plan9-2% cat t.c
	#include <u.h>
	#include <libc.h>

	main()
	{
		long elasticity = 8000L;
		double ratio = 0.1;

		/* this is fine */
		elasticity = (long)(((double)elasticity)*ratio);
		print("%ld\n", elasticity);

		/* this breaks with 8c */
		elasticity *= ratio;
		print("%ld\n", elasticity);

	}
	plan9-2% 8c t.c; 8l t.8
	plan9-2% 8.out
	800
	0
	plan9-2%


Its (almost) identical lunix counterpart, when compiled with gcc 3.2,
produces 800/80:

	mirtchov@fbsd$ cat t.c
	main()
	{
	        long elasticity = 8000L;
	        double ratio = 0.1;

		/* this is fine */
	        elasticity = (long)(((float)elasticity)*ratio);
	        printf("%ld\n", elasticity);

		/* this if fine with gcc 3.2 */
	        elasticity *= ratio;
	        printf("%ld\n", elasticity);

	}
	mirtchov@fbsd$ gcc t.c
	mirtchov@fbsd$ ./a.out
	800
	80
	mirtchov@fbsd$


Not looking to assign any blame, just letting you know...

andrey

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-30 22:40   ` David Presotto
@ 2004-01-31  0:57     ` Bruce Ellis
  2004-01-31  1:34       ` boyd, rounin
  2004-01-31  1:51       ` Bruce Ellis
  0 siblings, 2 replies; 17+ messages in thread
From: Bruce Ellis @ 2004-01-31  0:57 UTC (permalink / raw)
  To: 9fans

indeed.  the expression is being rewritten as

    elasticity *= (long)ratio;

com.c:196

same thing for + and - at line 169.

brucee
----- Original Message -----
From: "David Presotto" <presotto@closedmind.org>
To: <9fans@cse.psu.edu>
Sent: Saturday, January 31, 2004 9:40 AM
Subject: Re: [9fans] remember when C compiler used to produce working code? i don't!


> Looks like a problem in cc/com.c in tcomo().  I'm going to be away
> for a week and will take a crack at it when I get back.  If someone
> else wants to try in the mean time...


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31  0:57     ` Bruce Ellis
@ 2004-01-31  1:34       ` boyd, rounin
  2004-01-31  1:51       ` Bruce Ellis
  1 sibling, 0 replies; 17+ messages in thread
From: boyd, rounin @ 2004-01-31  1:34 UTC (permalink / raw)
  To: 9fans

> indeed.  the expression is being rewritten as
>
>     elasticity *= (long)ratio;

sure looked like it.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31  0:57     ` Bruce Ellis
  2004-01-31  1:34       ` boyd, rounin
@ 2004-01-31  1:51       ` Bruce Ellis
  2004-01-31  2:15         ` boyd, rounin
  2004-01-31  3:13         ` David Presotto
  1 sibling, 2 replies; 17+ messages in thread
From: Bruce Ellis @ 2004-01-31  1:51 UTC (permalink / raw)
  To: 9fans

on further inspection (and coffee) i would suggest that the
"sametype" test be changed so that in these cases the OCAST
is not inserted for <integral> asop <floating>.

the onus would then be on the individual compilers to handle
asops of this form, further complicating the asop code at
e.g. 8c/cgen.c:434 - what a tedious solution.

the reasoning (which may not be right) is that the port code
in cc cannot, in general, rewrite the tree; consider:

    *lp++ *= ratio;

8c/cgen.c uses reglcgen() for the hard lhs.

the other compilers have logically similar code to do this,
though most have more registers, so it's easier.

comments anyone?

brucee
----- Original Message -----
From: "Bruce Ellis" <brucee@chunder.com>
To: <9fans@cse.psu.edu>
Sent: Saturday, January 31, 2004 11:57 AM
Subject: Re: [9fans] remember when C compiler used to produce working code? i don't!


> indeed.  the expression is being rewritten as
>
>     elasticity *= (long)ratio;
>
> com.c:196
>
> same thing for + and - at line 169.
>
> brucee
> ----- Original Message -----
> From: "David Presotto" <presotto@closedmind.org>
> To: <9fans@cse.psu.edu>
> Sent: Saturday, January 31, 2004 9:40 AM
> Subject: Re: [9fans] remember when C compiler used to produce working code? i don't!
>
>
> > Looks like a problem in cc/com.c in tcomo().  I'm going to be away
> > for a week and will take a crack at it when I get back.  If someone
> > else wants to try in the mean time...
>


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31  1:51       ` Bruce Ellis
@ 2004-01-31  2:15         ` boyd, rounin
  2004-01-31  3:13         ` David Presotto
  1 sibling, 0 replies; 17+ messages in thread
From: boyd, rounin @ 2004-01-31  2:15 UTC (permalink / raw)
  To: 9fans

> the reasoning (which may not be right) is that the port code
> in cc cannot, in general, rewrite the tree; consider:
>
>     *lp++ *= ratio;

yeah, it could have arbitrarily nasty side effects to just
hack on in there and fix just this problem for just 8c.

i'd reckon you'd need to have good knowledge of the
compiler and the various architectures. no point
turning broken code into _very_ broken code.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31  1:51       ` Bruce Ellis
  2004-01-31  2:15         ` boyd, rounin
@ 2004-01-31  3:13         ` David Presotto
  2004-01-31  7:40           ` Bruce Ellis
  1 sibling, 1 reply; 17+ messages in thread
From: David Presotto @ 2004-01-31  3:13 UTC (permalink / raw)
  To: 9fans

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

You're right, copying the left node for OAS(OP) would be a bummer in cc.
We could conceivably do the work in cc but I can't see an easy way to do
it.

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

From: "Bruce Ellis" <brucee@chunder.com>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] remember when C compiler used to produce working code? i don't!
Date: Sat, 31 Jan 2004 12:51:00 +1100
Message-ID: <029701c3e79d$8af35370$8201a8c0@cc77109e>

on further inspection (and coffee) i would suggest that the
"sametype" test be changed so that in these cases the OCAST
is not inserted for <integral> asop <floating>.

the onus would then be on the individual compilers to handle
asops of this form, further complicating the asop code at
e.g. 8c/cgen.c:434 - what a tedious solution.

the reasoning (which may not be right) is that the port code
in cc cannot, in general, rewrite the tree; consider:

    *lp++ *= ratio;

8c/cgen.c uses reglcgen() for the hard lhs.

the other compilers have logically similar code to do this,
though most have more registers, so it's easier.

comments anyone?

brucee
----- Original Message -----
From: "Bruce Ellis" <brucee@chunder.com>
To: <9fans@cse.psu.edu>
Sent: Saturday, January 31, 2004 11:57 AM
Subject: Re: [9fans] remember when C compiler used to produce working code? i don't!


> indeed.  the expression is being rewritten as
>
>     elasticity *= (long)ratio;
>
> com.c:196
>
> same thing for + and - at line 169.
>
> brucee
> ----- Original Message -----
> From: "David Presotto" <presotto@closedmind.org>
> To: <9fans@cse.psu.edu>
> Sent: Saturday, January 31, 2004 9:40 AM
> Subject: Re: [9fans] remember when C compiler used to produce working code? i don't!
>
>
> > Looks like a problem in cc/com.c in tcomo().  I'm going to be away
> > for a week and will take a crack at it when I get back.  If someone
> > else wants to try in the mean time...
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31  3:13         ` David Presotto
@ 2004-01-31  7:40           ` Bruce Ellis
  2004-01-31  9:03             ` andrey mirtchovski
  2004-01-31 17:59             ` Scott Schwartz
  0 siblings, 2 replies; 17+ messages in thread
From: Bruce Ellis @ 2004-01-31  7:40 UTC (permalink / raw)
  To: 9fans

i've worked out how to do it in cc but it will produce a lot more
code than the solution i presented.  under the "rare, and perhaps
stupid, things get what they deserve" unofficiaol clause of kenc
it may be adequate.

yes, only one example.

i'm still thinking the cgen way is the better alternative.  the asop
code already has case analysis, yeah like bitfield *= i, and they
all look alike and can be optimized further than they are (as
discussed in private presto communication).

i'm willing to do either.

any comments from people who are very familiar with the
compiler are welcome.

comments about the "rare" philosophy are also welcome.

brucee
----- Original Message -----
From: "David Presotto" <presotto@closedmind.org>
To: <9fans@cse.psu.edu>
Sent: Saturday, January 31, 2004 2:13 PM
Subject: Re: [9fans] remember when C compiler used to produce working code? i don't!


> You're right, copying the left node for OAS(OP) would be a bummer in cc.
> We could conceivably do the work in cc but I can't see an easy way to do
> it.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31  7:40           ` Bruce Ellis
@ 2004-01-31  9:03             ` andrey mirtchovski
  2004-01-31 10:08               ` David Tolpin
  2004-01-31 14:19               ` boyd, rounin
  2004-01-31 17:59             ` Scott Schwartz
  1 sibling, 2 replies; 17+ messages in thread
From: andrey mirtchovski @ 2004-01-31  9:03 UTC (permalink / raw)
  To: 9fans

> comments about the "rare" philosophy are also welcome.

I don't know what ANSI C says the result should be, so I was hoping
someone would comment on that.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31  9:03             ` andrey mirtchovski
@ 2004-01-31 10:08               ` David Tolpin
  2004-01-31 14:19               ` boyd, rounin
  1 sibling, 0 replies; 17+ messages in thread
From: David Tolpin @ 2004-01-31 10:08 UTC (permalink / raw)
  To: 9fans

andrey mirtchovski:
> > comments about the "rare" philosophy are also welcome.
>
> I don't know what ANSI C says the result should be, so I was hoping
> someone would comment on that.
>

ISO C

6.5.16.2 Compound Assignment

....

Semantics

A compound assignment of the form E1 op= E2 differs from the simple assignment
expression E1 = E1 op (E2) only in that the lvalue E1 is evaluated only once.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31  9:03             ` andrey mirtchovski
  2004-01-31 10:08               ` David Tolpin
@ 2004-01-31 14:19               ` boyd, rounin
  2004-01-31 14:57                 ` Bruce Ellis
  1 sibling, 1 reply; 17+ messages in thread
From: boyd, rounin @ 2004-01-31 14:19 UTC (permalink / raw)
  To: 9fans

> I don't know what ANSI C says the result should be, so I was hoping
> someone would comment on that.

i had some old memory that K&R C said this was a bad idea.

i've been waiting for doug to pronounce what ansi C says.

i try to avoid floating point at all costs.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31 14:19               ` boyd, rounin
@ 2004-01-31 14:57                 ` Bruce Ellis
  0 siblings, 0 replies; 17+ messages in thread
From: Bruce Ellis @ 2004-01-31 14:57 UTC (permalink / raw)
  To: 9fans

ok.  enough said - i've fixed it.  it was very little code.  i'll consult
with dave on his return and we'll get it integrated.  of course i'll
test it a bit more ....

brucee
----- Original Message -----
From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Sent: Sunday, February 01, 2004 1:19 AM
Subject: Re: [9fans] remember when C compiler used to produce working code? i don't!


> > I don't know what ANSI C says the result should be, so I was hoping
> > someone would comment on that.
>
> i had some old memory that K&R C said this was a bad idea.
>
> i've been waiting for doug to pronounce what ansi C says.
>
> i try to avoid floating point at all costs.



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31  7:40           ` Bruce Ellis
  2004-01-31  9:03             ` andrey mirtchovski
@ 2004-01-31 17:59             ` Scott Schwartz
  2004-01-31 19:23               ` Rob Pike
  1 sibling, 1 reply; 17+ messages in thread
From: Scott Schwartz @ 2004-01-31 17:59 UTC (permalink / raw)
  To: 9fans

> comments about the "rare" philosophy are also welcome.

Better to halt with an error than silently generate bad code.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31 17:59             ` Scott Schwartz
@ 2004-01-31 19:23               ` Rob Pike
  2004-01-31 19:59                 ` Bruce Ellis
  2004-01-31 20:42                 ` Charles Forsyth
  0 siblings, 2 replies; 17+ messages in thread
From: Rob Pike @ 2004-01-31 19:23 UTC (permalink / raw)
  To: 9fans

>> comments about the "rare" philosophy are also welcome.
>
> Better to halt with an error than silently generate bad code.

true, but credit should also be given to the overall quality of the
compiler.
bug reports have been rare.

-rob



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31 19:23               ` Rob Pike
@ 2004-01-31 19:59                 ` Bruce Ellis
  2004-01-31 20:42                 ` Charles Forsyth
  1 sibling, 0 replies; 17+ messages in thread
From: Bruce Ellis @ 2004-01-31 19:59 UTC (permalink / raw)
  To: 9fans

sorry if it seemed i was suggesting *ever* generating wrong code,
just that the code generated for really rare cases can be way suboptimal.

in any case it's fixed now - it turns out that most of the code was
already in 8c/cgen.c - it just wasn't being triggered because of
the incorrect rewrite.  5c/cgen.c needed just a few lines.

brucee.
----- Original Message -----
From: "Rob Pike" <rob@mightycheese.com>
To: <9fans@cse.psu.edu>
Sent: Sunday, February 01, 2004 6:23 AM
Subject: Re: [9fans] remember when C compiler used to produce working code? i don't!


> >> comments about the "rare" philosophy are also welcome.
> >
> > Better to halt with an error than silently generate bad code.
>
> true, but credit should also be given to the overall quality of the
> compiler.
> bug reports have been rare.
>
> -rob



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [9fans] remember when C compiler used to produce working code? i don't!
  2004-01-31 19:23               ` Rob Pike
  2004-01-31 19:59                 ` Bruce Ellis
@ 2004-01-31 20:42                 ` Charles Forsyth
  1 sibling, 0 replies; 17+ messages in thread
From: Charles Forsyth @ 2004-01-31 20:42 UTC (permalink / raw)
  To: 9fans

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

absolutely, to the extent that i can't remember suffering one myself, over frighteningly many
years now and five or six architectures.  even with the newish AVR compiler, i always
suspect my own code, and usually: that's the right answer.

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

From: Rob Pike <rob@mightycheese.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] remember when C compiler used to produce working code? i don't!
Date: Sat, 31 Jan 2004 11:23:27 -0800
Message-ID: <F264FA26-5422-11D8-B35B-000A95B984D8@mightycheese.com>

>> comments about the "rare" philosophy are also welcome.
>
> Better to halt with an error than silently generate bad code.

true, but credit should also be given to the overall quality of the
compiler.
bug reports have been rare.

-rob

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2004-01-31 20:42 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-30 22:05 [9fans] remember when C compiler used to produce working code? i don't! andrey mirtchovski
2004-01-30 22:29 ` David Presotto
2004-01-30 22:40   ` David Presotto
2004-01-31  0:57     ` Bruce Ellis
2004-01-31  1:34       ` boyd, rounin
2004-01-31  1:51       ` Bruce Ellis
2004-01-31  2:15         ` boyd, rounin
2004-01-31  3:13         ` David Presotto
2004-01-31  7:40           ` Bruce Ellis
2004-01-31  9:03             ` andrey mirtchovski
2004-01-31 10:08               ` David Tolpin
2004-01-31 14:19               ` boyd, rounin
2004-01-31 14:57                 ` Bruce Ellis
2004-01-31 17:59             ` Scott Schwartz
2004-01-31 19:23               ` Rob Pike
2004-01-31 19:59                 ` Bruce Ellis
2004-01-31 20:42                 ` Charles Forsyth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).