Xref: news-dnh.mv.net comp.os.msdos.djgpp:2575
Path: news-dnh.mv.net!mv!news.sprintlink.net!gol2!gol1!gol1!not-for-mail
From: turnbull AT gol1 DOT gol DOT com (Stephen J. Turnbull)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Coprocessor nuisance...
Date: 12 Oct 1995 11:48:58 +0900
Organization: Global OnLine Japan
Lines: 61
References: <DG1v9q DOT 2LJ AT jade DOT mv DOT net> <3076a4f0 DOT sandmann AT clio DOT rice DOT edu>
Nntp-Posting-Host: gol1.gol.com
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

In article <3076a4f0 DOT sandmann AT clio DOT rice DOT edu>,
Charles Sandmann  <sandmann AT clio DOT rice DOT edu> wrote:
>> cc1 is called.  Cc1 works fine for a little bit, but then it dies
>> with the message "Coprocessor not found."  Any help on this would
>> be appreciated, and if anyone needs any additional info about
>> what's going on, just ask. (;
>
>I'm assuming you are using V2 beta 3.  I have seen a similar reports before,
>so there is probably a real problem with FPU-less machines.  The first 
>thing I would suggest is making sure all the exe images being run have a 
>date more recent than Aug 1, and there are no V1.x images in the path which
>may be run.  If the problem still exists, someone with a FPU-less machine
>will need to debug this, since everyone on the development team has a system
>with an FPU.  Is CC1 the only image which shows this problem?

I am using V2 beta 3.  I had no problem with the DJGPP v2 beta 3 
distribution itself.  My PATH puts the v2 beta 3 bin directory *first*, 
then the v1.12.maint4 bin directory, then other stuff.  I use

GO32=emu /usr/djgpp/2.0/bin/emu387.dxe
387=NO

(actually with some twiddles added so I could fiddle with the settings 
from the command line using environment variables, I guess I prepended + 
and use some variables in the path) in DJGPP.ENV.

I was able to compile all of Ghostscript (recent beta) with this.  
Ghostscript then proceeded to crash with a SIGNOFP in the following 
environments:

* same as build
* no GO32 variable, no 387 variable
* GO32 as above, 387=YES
* GO32 as above, 387=QUERY
* running Q87, a protected mode 387 emulator that happily supports DOS4GW 
  with no GO32 or 387 variable
* running Q87 with no GO32 varaible and 387=YES

all identical stack dumps.  Symify says it happens somewhere in gs's main
module (I don't feel like recompiling with all symbols global to find out
exactly where).  The machine involved is an IBM StinkPad (*don't* even
think about a StinkPad unless you never ever want to use it for anything
but Windows---it seems designed to make life impossible for all other
environments) 330cs. 

I had no problem compiling a simple test program (you can see it in my 
bug report on www.delorie.com).  It also crashed at run-time, exactly at 
the point of evaluating a floating point expression.

I suspect that CC1 is crashing when it attempts to evaluate a constant 
floating point expression in the case reported, but I don't have access 
to the code so that's just a guess.

I did not have these problems with v2.0 beta 2.  Coprocessor support was 
not transparent, but I was able to run Ghostscript.  Also simple test 
programs using floating point.

-- 
Stephen Turnbull
Yaseppochi-Gumi           DJGPP mailing list archives and v2.0 beta at
http://turnbull.sk.tsukuba.ac.jp/yaseppochi-gumi.html  (anon fTP, too)