a compiler bug?

a compiler bug?

[forsyth]

here is what i think is a correct fix for 8c; assuming it's right,
a similar change will be needed to cgen.c in all other compilers.

vortex% diff $home/cd/cmd/8c cgen.c
1194c1194
< 		 * rewrite so lhs has no fn call
---
> 		 * rewrite so lhs has no side effects
1196c1196
< 		if(nn != Z && nn->complex >= FNX) {
---
> 		if(side(nn)) {

a compiler bug?

[forsyth]

i'll correct my own correction:

vortex% diff $home/cd/cmd/8c cgen.c
1194c1194
< 		 * rewrite so lhs has no fn call
---
> 		 * rewrite so lhs has no side effects
1196c1196
< 		if(nn != Z && nn->complex >= FNX) {
---
> 		if(nn != Z && side(nn)) {

a compiler bug?

[Eran]

Hi,

I found that assigning structure displays into an array of structures 
with a post-increment index yields strange results.
The value of the index is wrong and the array has "holes".
The following C program demonstrates this behavior:

	#include <u.h>
	#include <libc.h>
	
	enum	{
		N = 10,
	};
	
	typedef	struct	{
		int p;
		int q;
	} T;
	
	static int na, nb;
	
	static T a[N], b[N];
	
	void
	main(int argc, char *argv[])
	{
		int i;
		T x;
	
		for (i = 0; i < N; i++) {
			x = (T){10+i, 20+i};
			a[na++] = x;
			b[nb++] = (T){10+i, 20+i};
		}
	
		print("na=%d nb=%d\n", na, nb);
	
		for (i = 0; i < N; i++)
			print("a[%d]: %d %d\n", i, a[i].p, a[i].q);
	
		for (i = 0; i < N; i++)
			print("b[%d]: %d %d\n", i, b[i].p, b[i].q);
	}
	
The contents of a and b should be equal, as well as na and nb.
The output is:
	
	term% 8.out
	na=10 nb=20
	a[0]: 10 20
	a[1]: 11 21
	a[2]: 12 22
	a[3]: 13 23
	a[4]: 14 24
	a[5]: 15 25
	a[6]: 16 26
	a[7]: 17 27
	a[8]: 18 28
	a[9]: 19 29
	b[0]: 10 0
	b[1]: 0 20
	b[2]: 11 0
	b[3]: 0 21
	b[4]: 12 0
	b[5]: 0 22
	b[6]: 13 0
	b[7]: 0 23
	b[8]: 14 0
	b[9]: 0 24
	
Regards,

	Eran

Eran Gabber		 			E-mail: eran@bell-labs.com
Bell Labs, Room MH 2C-234A			http://cm.bell-labs.com/is/eran
600 Mountain Avenue				Phone:	1-908-582-4354
Murray Hill, NJ 07974				Fax:	1-908-582-5809