kc cross-compiler bug on PC

kc cross-compiler bug on PC

[forsyth]

given the following program as p.c:

------
typedef struct Point Point;
typedef struct Rectangle Rectangle;
struct	Point
{
	int	x;
	int	y;
};

struct Rectangle
{
	Point min;
	Point max;
};
#define	Pt(x, y)		((Point){(x), (y)})
#define	Rect(x1, y1, x2, y2)	((Rectangle){Pt(x1, y1), Pt(x2, y2)})
#define	Rpt(p1, p2)		((Rectangle){(p1), (p2)})
void
main(int argc, char **argv)
{
	Rectangle r;

	r = Rect(0, 0, 1152, 900);
	print("%d %d %d %d\n", r.min.x, r.min.y, r.max.x, r.max.y);
}
------

on a 486, compile with kc/kl and interpret with ki:

pc% kc t.c
pc% kc p.c
p.c:23 function args not checked: print
pc% kl p.k -lc
pc% ki k.out
ki
:r
900 0 0 0
exits(main)
stopped at #3250 _exits+c

wrong.

now, on a 68020 [probably any non-PC, including a sparc!], do the same:

68k% kc p.c
p.c:23 function args not checked: print
68k% kl p.k -lc
68k% ki k.out
ki
:r
0 0 1152 900
exits(main)
stopped at #3250 _exits+c

right!

if you compare the -S output of kc on both machines, the difference
is obvious.

this bug prevents the correct cross-compilation for a Sparc from a PC
of the sparc kernel, graphics programs, and anything else that uses
the (MUMBLE){a,b,c} extension to expressions.
those two architectures deserve each other, i admit.

the following change to kc seems to fix that one, but i don't know my way round kc
well enough to make guarantees about the fix, or about any related problems:

vortex% diff old /sys/src/cmd/kc/cgen.c
880c880
< 			nod4.xoffset = t->offset;
---
> 			nod4.vconst = t->offset;