9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Building Go/386
@ 2013-08-31 14:36 lucio
  2013-08-31 15:11 ` erik quanstrom
  0 siblings, 1 reply; 13+ messages in thread
From: lucio @ 2013-08-31 14:36 UTC (permalink / raw)
  To: 9fans

This looks ugly!

cmd/8g
8c 1568: suicide: sys: trap: fault read addr=0x0 pc=0x0003718d
go tool dist: FAILED: /bin/8c -FTVw -I/n/shackle/go/include/plan9 -I/n/shackle/go/include/plan9/386 -I/n/shackle/go/src/cmd/ld -I /n/shackle/go/src/cmd/8g -o $WORK/ggen.8 /n/shackle/go/src/cmd/8g/ggen.c: '/n/shackle/go/pkg/tool/plan9_386/8g' does not exist
warning: /n/shackle/go/src/cmd/8g/gobj.c:38 result of operation not used
shackle% acid 1568
/proc/1568/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: lstk()
abort()+0x0 /sys/src/libc/9sys/abort.c:6
regalloc(o=0x0,tn=0x13bcf8,n=0xdfff5a78)+0xbb /sys/src/cmd/8c/txt.c:314
biggen(a=0x3911c,code=0x3ce5c,l=0x13bcf8,r=0xdfff5c48,t=0x0,true=0x0)+0xd88 /sys/src/cmd/8c/cgen64.c:1522
	args=0x1732e
	to=0x0
	ro=0x0
	lo=0x0
	cp=0x3ce61
	c=0x3ce5c
	g=0x1
	i=0x0
	j=0x13b908
	ot=0x0
	tmps=0x0
	tl=0x0
	tr=0x0
	op=0x82
	lt=0x4ad00
	pr=0x0
cgen64(nn=0x13bcf8,n=0x136158)+0x18b2 /sys/src/cmd/8c/cgen64.c:1784
	cmp=0x0
	sh=0x0
	d=0x0
	optab=0x3a214
	args=0x3911c
	dr=0x1
	l=0x13bcf8
	r=0xdfff5c48
	li=0x0
	ri=0x3
	lri=0x2
	t=0x13bcf8
	dt=0x4ad78
	nod2=0x0
	nod3=0x0
	c=0x0
	nod1=0x0
	m=0x1
	s=0x0
	op=0x0
	true=0x0
	nod5=0x13a8b8
	nod4=0x0
	cp=0x13a630
	si=0x1e
sugen(w=0x8,nn=0x13bcf8,n=0x136158)+0x160 /sys/src/cmd/8c/cgen.c:1701
	t=0x0
	nod1=0x1
	nod2=0x2
	nod0=0x0
	l=0x3
	r=0x3
	nod3=0x0
	nod4=0x3a214
	h=0x3
	p1=0x0
	x=0x0
	v=0x1
	c=0x0
cgen64(nn=0x13bcf8,n=0x13b998)+0x1dcd /sys/src/cmd/8c/cgen64.c:1734
	cmp=0x0
	sh=0x0
	d=0x0
	optab=0x3fa74
	args=0x39194
	dr=0x1
	l=0x136158
	r=0x13bdd0
	li=0x0
	ri=0x0
	lri=0x0
	t=0x13bcf8
	dt=0x0
	nod2=0x0
	nod3=0xdfff6738
	c=0x0
	nod1=0x0
	m=0x0
	s=0x0
	op=0x0
	true=0x0
	nod5=0x18d5d
	nod4=0x0
	cp=0x0
	si=0x0
sugen(w=0x8,nn=0x13bcf8,n=0x13b998)+0x160 /sys/src/cmd/8c/cgen.c:1701
	t=0x70
	nod1=0x2
	nod2=0x5c
	nod0=0x0
	l=0xdfff66d4
	r=0x138bc0
	nod3=0x0
	nod4=0x0
	h=0x0
	p1=0xdfff627c
	x=0x0
	v=0x1
	c=0x0
cgen64(nn=0xdfff6f98,n=0x1361e8)+0x2bc6 /sys/src/cmd/8c/cgen64.c:2526
	cmp=0x0
	sh=0x0
	d=0x13bcf8
	optab=0x1732e
	args=0x18d5d
	dr=0x0
	l=0x13b998
	r=0x180d7
	li=0x0
	ri=0x0
	lri=0x0
	t=0x1b
	dt=0xdfff6f98
	nod2=0x1b070
	nod3=0x0
	c=0xdfff6490
	nod1=0x8
	m=0x0
	s=0x1
	op=0x0
	true=0x0
	nod5=0xdfff627c
	nod4=0x44
	cp=0x70
	si=0x0
cgen(nn=0xdfff6f98,n=0x1361e8)+0x28d1 /sys/src/cmd/8c/cgen.c:1125
	r=0x0
	o=0x1b
	curs=0x0
	l=0x13b998
	nod=0x70
	nod1=0x0
	hardleft=0x1
	nod2=0x0
	c=0x180c4
	v=0xdfff6f98
	nod3=0x135e80
	nod4=0x180d7
	onod=0x0
	p1=0xdfff6f98
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x1361e8,tn1=0xdfff6f98)+0x1ca /sys/src/cmd/8c/txt.c:231
	nod=0x0
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x136230,tn1=0xdfff6f98)+0x72 /sys/src/cmd/8c/txt.c:187
	nod=0x0
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x136080,tn1=0xdfff6f98)+0x72 /sys/src/cmd/8c/txt.c:187
	nod=0x0
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x135f60,tn1=0xdfff6f98)+0x72 /sys/src/cmd/8c/txt.c:187
	nod=0x0
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x135ec8,tn1=0xdfff6f98)+0x72 /sys/src/cmd/8c/txt.c:187
	nod=0xdfff67f4
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x135e38,tn1=0xdfff6f98)+0x72 /sys/src/cmd/8c/txt.c:187
	nod=0x0
gargs(n=0x135e38,tn1=0xdfff6f98,tn2=0xdfff6f50)+0x98 /sys/src/cmd/8c/txt.c:160
	regs=0x0
	fnxargs=0x193bb
	fnxp=0xdfff6858
cgen(nn=0xdfff718c,n=0x136278)+0x3763 /sys/src/cmd/8c/cgen.c:916
	r=0x135e38
	o=0x27
	curs=0x0
	l=0x135d60
	nod=0x0
	nod1=0x135fa8
	hardleft=0x0
	nod2=0x1
	c=0x0
	v=0x0
	nod3=0x8
	nod4=0x0
	onod=0xdfff725c
	p1=0xdfff718c
cgen(nn=0x0,n=0x1362c0)+0x121b /sys/src/cmd/8c/cgen.c:123
	r=0x136278
	o=0x6
	curs=0x0
	l=0x135d18
	nod=0x0
	nod1=0x136230
	hardleft=0x0
	nod2=0x1361e8
	c=0xa
	v=0x4ad78
	nod3=0x1a32a
	nod4=0x4ad78
	onod=0x1c40b
	p1=0x135d18
gen(n=0x1362c0)+0x126 /sys/src/cmd/cc/pgen.c:534
	o=0x6
	l=0x1
	nod=0x0
	rn=0x135c40
	sp=0x4acb0
	cn=0x14f2f
	sbc=0x135ad0
	snbreak=0x135c40
	spb=0x0
	scc=0x135c40
	spc=0x135c40
	sncontin=0x1ea68
	f=0x135cd0
	oldreach=0x14f2f
gen(n=0x136350)+0xb53 /sys/src/cmd/cc/pgen.c:515
	o=0x2d
	l=0x135cd0
	nod=0x0
	rn=0x4c7d8
	sp=0x13b878
	cn=0x14f2f
	sbc=0x135690
	snbreak=0x1ac1b
	spb=0x1
	scc=0x135720
	spc=0x0
	sncontin=0x1ea57
	f=0x135720
	oldreach=0x28
gen(n=0x136428)+0x5ed /sys/src/cmd/cc/pgen.c:421
	o=0x26
	l=0x1363e0
	nod=0x0
	rn=0x4c868
	sp=0x13ae58
	cn=0x14f2f
	sbc=0xffffffff
	snbreak=0x0
	spb=0x13aee8
	scc=0xffffffff
	spc=0x13aea0
	sncontin=0x0
	f=0xffffff61
	oldreach=0x14f2f
gen(n=0x136500)+0xbbb /sys/src/cmd/cc/pgen.c:524
	o=0x2d
	l=0x133a50
	nod=0x0
	rn=0x0
	sp=0x13a3a8
	cn=0x0
	sbc=0x0
	snbreak=0x0
	spb=0x80000000
	scc=0x0
	spc=0x0
	sncontin=0x0
	f=0xdfff74b8
	oldreach=0x1
codgen(nn=0x132668,n=0x132890)+0x195 /sys/src/cmd/cc/pgen.c:72
	n1=0x1323e0
	sp=0x136590
yyparse()+0x3dd /sys/src/cmd/cc/cc.y:1741
	save1=0x0
	save2=0x0
	save3=0x0
	save4=0x0
	yystate=0x2
	yychar=0xffffffff
	yys=0x0
	yyp=0xdfff7654
	yyn=0xfffffc18
	yypt=0xdfff76cc
	w=0x0
	n=0x0
	s=0x0
compile(file=0xdfffefa8,ndef=0x0,defs=0x0)+0x2d0 /sys/src/cmd/cc/lex.c:291
	ofile=0x732f6e2f
	p=0xdfffecc9
	incfile=0x3638332f
	c=0x3
	fd=0x0
	av=0x0
	i=0x0
	opt=0x0
main(argv=0xdfffeef8,argc=0x1)+0x17b /sys/src/cmd/cc/lex.c:154
	maxdef=0x0
	ndef=0x0
	defs=0x0
	_argc=0x6f
	_args=0xdfffef8a
	p=0x0
	np=0x0
	nproc=0x0
	c=0x0
	nout=0x0
	status=0x0
_main+0x31 /sys/src/libc/386/main9.s:16
acid:

My gut says this is a Plan 9 problem: something tickled a bug in 8c.
I hope someone here can diagnose the issue.

I needed to modify /sys/include/bio.h as well as
/sys/src/libbio/^(bgetc.c bputc.c) to get this far in the Go build; I
have nothing against adding Bgetle2(), Bgetle4(), Bputle2() and
Bputle4() to libbio, I do wish I had seen that coming.

We do seem to be losing ground to the Go developers, I have a feeling
that it is going to be hard to catch up.

++L

PS: One irritant I would gladly get rid of is the sheer number of
warnings that are being produced:

cmd/cc
warning: /n/shackle/go/src/cmd/cc/y.tab.c:1785[/n/shackle/go/src/cmd/cc/y.tab.c:3489] result of operation not used
warning: /n/shackle/go/src/cmd/cc/y.tab.c:1785[/n/shackle/go/src/cmd/cc/y.tab.c:3489] result of operation not used
warning: /n/shackle/go/src/cmd/cc/y.tab.c:1791[/n/shackle/go/src/cmd/cc/y.tab.c:3495] result of operation not used
warning: /n/shackle/go/src/cmd/cc/y.tab.c:1791[/n/shackle/go/src/cmd/cc/y.tab.c:3495] result of operation not used

as an example.  I haven't quite figured out what triggers these, nor
how to eliminate them.




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

* Re: [9fans] Building Go/386
  2013-08-31 14:36 [9fans] Building Go/386 lucio
@ 2013-08-31 15:11 ` erik quanstrom
  2013-08-31 17:09   ` lucio
                     ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: erik quanstrom @ 2013-08-31 15:11 UTC (permalink / raw)
  To: 9fans

> My gut says this is a Plan 9 problem: something tickled a bug in 8c.
> I hope someone here can diagnose the issue.

sure.  this is not a bug per ce.  it's a limitation of 8c's technique
for registerizing vlongs given the restricted register set of the 386.

8c takes an initial stab at registerizing expressions.  if it needs
more than AX-DI, it can't be compiled without breaking down the
expressions a bit.  spilling is not implemented at this level.

since even ghostscript doesn't get into this state, i'd be interested
in the line of code (and types of the variables) that hits this fatal
condition.

imho the diag() abort() should be replaced with a fatal(), since
-X will give anyone interested a broken process to debug, and leave
anyone not interested alone.

> I needed to modify /sys/include/bio.h as well as
> /sys/src/libbio/^(bgetc.c bputc.c) to get this far in the Go build; I
> have nothing against adding Bgetle2(), Bgetle4(), Bputle2() and
> Bputle4() to libbio, I do wish I had seen that coming.
>
> We do seem to be losing ground to the Go developers, I have a feeling
> that it is going to be hard to catch up.

perhaps chasing the tip isn't going to work.

- erik



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

* Re: [9fans] Building Go/386
  2013-08-31 15:11 ` erik quanstrom
@ 2013-08-31 17:09   ` lucio
  2013-08-31 18:12   ` lucio
  2013-09-07 11:19   ` Anthony Martin
  2 siblings, 0 replies; 13+ messages in thread
From: lucio @ 2013-08-31 17:09 UTC (permalink / raw)
  To: 9fans

> since even ghostscript doesn't get into this state, i'd be interested
> in the line of code (and types of the variables) that hits this fatal
> condition.

I'll see if I can track down more details, I'm relieved there are
others out there who can fathom out these situations (and show some
concern)...

++L




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

* Re: [9fans] Building Go/386
  2013-08-31 15:11 ` erik quanstrom
  2013-08-31 17:09   ` lucio
@ 2013-08-31 18:12   ` lucio
  2013-08-31 21:16     ` erik quanstrom
  2013-09-07 11:19   ` Anthony Martin
  2 siblings, 1 reply; 13+ messages in thread
From: lucio @ 2013-08-31 18:12 UTC (permalink / raw)
  To: 9fans

> since even ghostscript doesn't get into this state, i'd be interested
> in the line of code (and types of the variables) that hits this fatal
> condition.

Here it is, "before" and "after" I applied some trivial "simplification":

/*
		for(i=0, j=(stkptrsize-stkzerosize)/widthptr*2; i<stkzerosize; i+=widthptr, j+=2)
			if(bvget(bv, j) || bvget(bv, j+1))
				p = appendp(p, AMOVL, D_CONST, 0, D_SP+D_INDIR, frame-stkzerosize+i);
*/
		i = 0;
		j = (stkptrsize-stkzerosize)/widthptr*2;
		while (i < stkzerosize) {
			int f = frame - stkzerosize + i;
			if(bvget(bv, j) || bvget(bv, j+1)) {
				p = appendp(p, AMOVL, D_CONST, 0, D_SP+D_INDIR, f);
			}
			i += widthptr;
			j += 2;
		}

around line 40 in $GOROOT/src/cmd/8g/ggen.c.

Thank you, Erik, for your invaluable input, it seems to work now.

++L




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

* Re: [9fans] Building Go/386
  2013-08-31 18:12   ` lucio
@ 2013-08-31 21:16     ` erik quanstrom
  2013-09-02 18:15       ` Nick Owens
  0 siblings, 1 reply; 13+ messages in thread
From: erik quanstrom @ 2013-08-31 21:16 UTC (permalink / raw)
  To: 9fans

> /*
> 		for(i=0, j=(stkptrsize-stkzerosize)/widthptr*2; i<stkzerosize; i+=widthptr, j+=2)
> 			if(bvget(bv, j) || bvget(bv, j+1))
> 				p = appendp(p, AMOVL, D_CONST, 0, D_SP+D_INDIR, frame-stkzerosize+i);
> */
> 		i = 0;
> 		j = (stkptrsize-stkzerosize)/widthptr*2;
> 		while (i < stkzerosize) {
> 			int f = frame - stkzerosize + i;
> 			if(bvget(bv, j) || bvget(bv, j+1)) {
> 				p = appendp(p, AMOVL, D_CONST, 0, D_SP+D_INDIR, f);
> 			}
> 			i += widthptr;
> 			j += 2;
> 		}
>
> around line 40 in $GOROOT/src/cmd/8g/ggen.c.
>
> Thank you, Erik, for your invaluable input, it seems to work now.

no problems.  is this the minimum amount of reorginization necessary?

- erik



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

* Re: [9fans] Building Go/386
  2013-08-31 21:16     ` erik quanstrom
@ 2013-09-02 18:15       ` Nick Owens
  2013-09-02 20:50         ` Rob Pike
  2013-09-04  6:07         ` lucio
  0 siblings, 2 replies; 13+ messages in thread
From: Nick Owens @ 2013-09-02 18:15 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

hello 9fans and gophers,

i have been using go on 9front for a while now. however, an issue
with 8c's inclusion mechanism was recently introduced.

the commit was https://codereview.appspot.com/12568043 which assumes
that includes will be resolved relative to the file that included them,
not the wd of the compiler. you can see in the comments a bit of the
discussion. http://9.offblast.org/stuff/cfc3eab6195a shows this problem
more explicitly. d881cb1ffc14 is the most recent commit that i use now.

do you fellows have any idea how to resolve this? is this go or plan 9's
'fault'?

nick




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

* Re: [9fans] Building Go/386
  2013-09-02 18:15       ` Nick Owens
@ 2013-09-02 20:50         ` Rob Pike
  2013-09-02 21:51           ` erik quanstrom
  2013-09-04  6:07         ` lucio
  1 sibling, 1 reply; 13+ messages in thread
From: Rob Pike @ 2013-09-02 20:50 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I'm pretty sure C defines the include path to be relative to the file
that includes it. The compiler's working directory should be
irrelevant. I'm also pretty sure Plan 9's compiler gets this right, or
at least used to. So more information is required.

-rob



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

* Re: [9fans] Building Go/386
  2013-09-02 20:50         ` Rob Pike
@ 2013-09-02 21:51           ` erik quanstrom
  2013-09-02 22:08             ` Nick Owens
  0 siblings, 1 reply; 13+ messages in thread
From: erik quanstrom @ 2013-09-02 21:51 UTC (permalink / raw)
  To: 9fans

On Mon Sep  2 16:51:31 EDT 2013, robpike@gmail.com wrote:
> I'm pretty sure C defines the include path to be relative to the file
> that includes it. The compiler's working directory should be
> irrelevant. I'm also pretty sure Plan 9's compiler gets this right, or
> at least used to. So more information is required.

that still works, otherwise the kernel would not compile.

- erik



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

* Re: [9fans] Building Go/386
  2013-09-02 21:51           ` erik quanstrom
@ 2013-09-02 22:08             ` Nick Owens
  2013-09-03  0:28               ` erik quanstrom
  0 siblings, 1 reply; 13+ messages in thread
From: Nick Owens @ 2013-09-02 22:08 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, Sep 02, 2013 at 05:51:15PM -0400, erik quanstrom wrote:
> On Mon Sep  2 16:51:31 EDT 2013, robpike@gmail.com wrote:
> > I'm pretty sure C defines the include path to be relative to the file
> > that includes it. The compiler's working directory should be
> > irrelevant. I'm also pretty sure Plan 9's compiler gets this right, or
> > at least used to. So more information is required.
>
> that still works, otherwise the kernel would not compile.
>
> - erik
>

the trouble here is that go's src/libmach/8obj.c has '#include
"../cmd/8l/8.out.h"', and 8.out.h now has the newly added '#include
"../ld/textflag.h"'.

i see now that the kernel source has an instance of this, in
/sys/src/9/pc: 'fns.h:1: #include "../port/portfns.h"', but i'm not sure
how that is treated differently from this situation.

i did a small test, and made $home/bin/rc/8c which forces the -p flag of
8c to invoke cpp. when doing ./make.rc in go with this wrapper, the
include appears to be resolved correctly.

fwiw, the standard does not define the mechanism for includes to be
found at all, only that it is implementation-specific [1].

nick

[1] http://www.iso-9899.info/n1256.html#6.10.2



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

* Re: [9fans] Building Go/386
  2013-09-02 22:08             ` Nick Owens
@ 2013-09-03  0:28               ` erik quanstrom
  0 siblings, 0 replies; 13+ messages in thread
From: erik quanstrom @ 2013-09-03  0:28 UTC (permalink / raw)
  To: mischief, 9fans

> the trouble here is that go's src/libmach/8obj.c has '#include
> "../cmd/8l/8.out.h"', and 8.out.h now has the newly added '#include
> "../ld/textflag.h"'.
> 
> i see now that the kernel source has an instance of this, in
> /sys/src/9/pc: 'fns.h:1: #include "../port/portfns.h"', but i'm not sure
> how that is treated differently from this situation.

it is different because -I../port is part of CFLAGS.

i've just verified that the plan 9 c compilers interpret relative
paths relative to the original source file, not any included files,
but -p interprets relative to the file doing the including.
imo the compilers should be fixed, but it might require a few
fixes.  the easiest (smallest delta) solution would be for
8.out.h to include "../../cmd/ld/textflag.h" instead of "../ld/textflag.h".

i suppose this is just another reason not to include include files. ☺

- erik



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

* Re: [9fans] Building Go/386
  2013-09-02 18:15       ` Nick Owens
  2013-09-02 20:50         ` Rob Pike
@ 2013-09-04  6:07         ` lucio
  1 sibling, 0 replies; 13+ messages in thread
From: lucio @ 2013-09-04  6:07 UTC (permalink / raw)
  To: 9fans

> do you fellows have any idea how to resolve this? is this go or plan 9's
> 'fault'?

I have submitted CL 13303047 to address this with minimum disruption.
But now I'm not quite as sure as I was at the time...

++L




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

* Re: [9fans] Building Go/386
  2013-08-31 15:11 ` erik quanstrom
  2013-08-31 17:09   ` lucio
  2013-08-31 18:12   ` lucio
@ 2013-09-07 11:19   ` Anthony Martin
  2013-09-07 13:07     ` erik quanstrom
  2 siblings, 1 reply; 13+ messages in thread
From: Anthony Martin @ 2013-09-07 11:19 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

erik quanstrom <quanstro@quanstro.net> once said:
> since even ghostscript doesn't get into this state, i'd be interested
> in the line of code (and types of the variables) that hits this fatal
> condition.

I posted a small piece of code that triggers this on golang-dev.

Here it is:

% cat x.c
unsigned long long x;

int f(int);

void
test(void)
{
	int a;

	a = f(a-x+a);
}
% 8c x.c
8c 98: suicide: sys: trap: fault read addr=0x0 pc=0x0003712f
%

Cheers,
  Anthony



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

* Re: [9fans] Building Go/386
  2013-09-07 11:19   ` Anthony Martin
@ 2013-09-07 13:07     ` erik quanstrom
  0 siblings, 0 replies; 13+ messages in thread
From: erik quanstrom @ 2013-09-07 13:07 UTC (permalink / raw)
  To: 9fans

nice test case.

> % 8c x.c
> 8c 98: suicide: sys: trap: fault read addr=0x0 pc=0x0003712f

the reason "out of fixed registers" is not output is that Bprint
is used by diag.  abort() does allow bio buffers to be dumped,
and doesn't seem useful.

here's the 9atom solution:

; 9diff txt.c
/n/sources/plan9/sys/src/cmd/8c/txt.c:310,317 - txt.c:310,316
  		for(i=D_AX; i<=D_DI; i++)
  			if(reg[i] == 0)
  				goto out;
- 		diag(tn, "out of fixed registers");
- abort();
+ 		fatal(tn, "out of fixed registers");
  		goto err;

  	case TFLOAT:

- erik



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

end of thread, other threads:[~2013-09-07 13:07 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-31 14:36 [9fans] Building Go/386 lucio
2013-08-31 15:11 ` erik quanstrom
2013-08-31 17:09   ` lucio
2013-08-31 18:12   ` lucio
2013-08-31 21:16     ` erik quanstrom
2013-09-02 18:15       ` Nick Owens
2013-09-02 20:50         ` Rob Pike
2013-09-02 21:51           ` erik quanstrom
2013-09-02 22:08             ` Nick Owens
2013-09-03  0:28               ` erik quanstrom
2013-09-04  6:07         ` lucio
2013-09-07 11:19   ` Anthony Martin
2013-09-07 13:07     ` erik quanstrom

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).