Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!kth!draken!tut!santra!kolvi!dny
From: dny@kolvi.hut.fi (Dag Nygren)
Newsgroups: comp.unix.xenix
Subject: C-compiler bugs
Summary: Is there a fix ?
Keywords: xenix c-compiler cc
Message-ID: <176@kolvi.hut.fi>
Date: 25 May 89 00:19:31 GMT
Reply-To: dny@kolvi.hut.fi (Dag Nygren)
Organization: Helsinki University of Technology, Finland
Lines: 48

Just ran into a couple of bugs? in the C-compiler included in our
Xenix/386 2.3.1 system running on an ALR 20 MHz Flexcache .

Problem 1:
	Symptom: Compiler complaining about a code segment bigger
		than 64 K (This IS a 386 processor !!).
	env:	The program was generated with a Pascal to C translator
		and thus quite big. The code segment was probably bigger
		than 64 Kbyte.

Problem 2:
	symptom: Core dumps from correct code.
	env:	Same as above.
	comment: I traced this problem to branches generated with
		4 byte offsets by the code generator.
		The linker seems to think that they are 2 bytes long
		and even make a sign extension on them !!.
		Thats to say: your offset 0x00008765  is suddenly
		transformed to a 0xffff8765.
	Workaround:
		Run program until it dumps its core, dig out your adb,
		find the instruction where it stopped and change the ffff
		to 0000. Iterate until program works flawlessly :-()

Problem 3:
	Symptom: Compiler internal error: infinite spill
	Code:
		long x, y, z;
		long f1();

		y = f1(z + 2, 2 * (x / 4) + 4 + ( x % 2));

	Workaround:
		Do half of the computing into a temporary variable
		and then the function call with rest of the expression.

Am I using an old compiler version or .. 

If anyone has fixes, suggestions or just plain sympathy  please feel
free to contact me.

Email: dag@atomsf.uucp  or dny@kolvi.uucp

SnailMail:
	Dag Nygren
	Tornplanet 1 bost. 46
	02120 ESBO
	FINLAND