ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1992/04/03/13:22:22

Date: Fri, 3 Apr 92 11:51:43 -0600
From: wfs AT nicolas DOT ma DOT utexas DOT edu (Bill Schelter)
Posted-Date: Fri, 3 Apr 92 11:51:43 -0600
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: 1.06 beta
Reply-To: wfs AT nicolas DOT ma DOT utexas DOT edu
Status: O

I have compiled AKCL (austin kyoto common lisp) with the
gcc 2.1 in the beta release.   I ran tests of AKCL for correctness.

When I linked AKCL with the gcc106/lib/libc.a the link was fine and the
program ran for a while, but then got read errors when reading some
lisp files.

Linking with the djgcc105/lib/libc.a it ran correctly [still
running with the 106 go32 and emu387].  I compared the code size on a
set of about 15 files.  I was very surprised to see LARGER code with
gcc 2.1.  On most architectures it is the reverse, with substantially
smaller code under gcc 2.1.

[note it ran correctly with plain 105 modulo the various errors in modf
log exp etc]

Also I find that the program below

% gcc foo4.c
% go32 a.out 3.4
produced a '/' in the output (i am running under the emu387).
When I fixed the file doprnt.c so it would not do this, I found
I HAD to compile the library file doprnt.o using gcc105.   If I used
gcc 2.1 then I got total garbage when I ran it.

Ie
% gcc -c doprnt.c
% gcc foo4.o doprnt.o

I don't know if the gcc 2.1 is putting out floating point ops which the
emulator is not doing correctly or what was behind this.   


-------------foo4.c--------
double bil = 10000000000.0;
main(argc,argv)
     char *argv[];
{ double j;
  sscanf(argv[1],"%lf",&j);
  printf("%6.16e\n",j);
  j *= bil;
  j *= bil;
  j *= bil;
  printf("%6.16e\n",j);
  return 0;
}
--------end----------  








- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019