From owner-freebsd-current Wed May 27 17:41:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17800 for freebsd-current-outgoing; Wed, 27 May 1998 17:41:36 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ceia.nordier.com (slip139-92-122-74.joh.za.ibm.net [139.92.122.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17673 for ; Wed, 27 May 1998 17:40:50 -0700 (PDT) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.8/8.6.12) id CAA17560; Thu, 28 May 1998 02:34:37 +0200 (SAT) From: Robert Nordier Message-Id: <199805280034.CAA17560@ceia.nordier.com> Subject: Re: Replacing gcc as the system compiler (was Re: Fix for undefined "__error" and discussion of shared object versioning) In-Reply-To: <19980527225647.36082@follo.net> from Eivind Eklund at "May 27, 98 10:56:47 pm" To: eivind@yes.no (Eivind Eklund) Date: Thu, 28 May 1998 02:34:36 +0200 (SAT) Cc: rnordier@nordier.com, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Eivind Eklund wrote: > On Wed, May 27, 1998 at 10:04:11PM +0200, Robert Nordier wrote: > > You may need -ltdf during linking. > > What does this contain? Pretty much just 64-bit integer support. > > Have you looked closely at XANDF? I'm seeing two real hurdles (beyond > inertia) in using this as our main compiler: The use of asm() for some > macros in the kernel, and the use of linker sets. What do you think > our chance of working around these are? I think we can find reasonable ways over the technical hurdles. Possibly, though, we need to commit to supporting TenDRA as a secondary compiler initially, with a change 6-12 months down the line, if things work out. >From a few tests here, it is starting to look as though the trans386 optimization needs additional work. I know that some of the code I haved looked at was highly-optimized, so the slow times may be fairly readily correctable. > > > There is currently an unresolved bug in i386 long long support: avoid > > casting to long long. > > There is also what looks like a bug in handling of NULL - it doesn't > allow the use of ((void *)0) as NULL for function pointers. > > I may remember the C standard incorrectly (I haven't looked it up), > but I think it is required to. There is something strange there (even the error message looks wrong): Can't convert function pointer 'void *' to non-function pointer 'int ( * ) ( void )'. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message