🚀 go-pugleaf

I'm attempting to port g++1.31.0 to our pyramids.  I need to
determine if the remaining problems are mine(pyramid related) or
if they are bugs in general.

Inlines returning structs are broke:
In test6 this appears: Integer z = abs(x);  where x is an Integer.
The Integer created in abs is the one z becomes, however in
Integer(Integer&) *this points to the wrong address.
This happens for all inline functions that return structs I've looked at and
these all work when -Dinline= makes them normal functions.  Of course
the inlines are still in effect for stuff in libg++ so some tests still
crash.
	
test5a and test5b break gcc-c++:
They both have crashed it a couple of ways.  Sometimes an invalid param
list is reported at the end.  Sometimes invalid assembly is generated.
And sometimes a segmentation violation happens.  In that case
handle_braces() is on the stack.  Does anyone recognize this ... PLEASE.
This does not look pretty so I haven't pursued it.


On a happier note these bugs were identified:

Bug:	int a(), b(), c();  in a class def is causes a parse error
Fix:	replace commas with semis.  Zortech accepts the above code.

Bug:	ld++ put data at different addresses than where the relocated
	symbols pointed.  NMAGIC objects have, on pyramids, their
	.data sections page aligned and ld++ thought they were just
	word aligned.  OMAGIC .data segments were handled correct as word 
	aligned.
Fix:	make a N_DATADDR() macro like the what ld++ uses to
	calculate the start on the new .data segment to calculate
	where .data's start in objects.  N_DATADDR() is for struct exec so
	a new one for struct nlist was made.

Problem: pyramid's assembler doesn't accept $'s in symbols
Fix:	changed all $'s in cplus-tree.h and ld.c to .'s.  The ld.c ones
	were real fun to try and find :-(.  Thanks guys. Perhaps this
	character could be defined in one place for use everywhere else.

'Bug':	gcc1.31 ran out of virtual memory trying to compile
	cplus-parse.tab.c.  (this also happened when I tried to port this
	to my 3b1. Didn't expect the pyramid to have any difficulty)
'Fix':	used pyramid's cc.  We are low on swap space (40M total and 10M or 15M
	normally available). But how much does gcc need???
	What was the -DESKIT for?  Couldn't find ESKIT refered to anywhere.


Does 1.32 fix any of these bugs?


-- 
David Becker 
and another bug bites, and another bug bites   another bug bites the dust
db@kolonel.MN.ORG