dave@questar.QUESTAR.MN.ORG (David Becker) (01/31/89)
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