chouw@galaxy.cps.msu.edu (Wen Hwa Chou) (04/08/91)
There is nothing fancy in the included small C programs. When compiled as
"cc -o starnge strange.c" everything is OK. But when I tried it as
"cc -O -o strange strange.c" than the Slab is gone - I mean totally gone.
I would not even respond to the cmd-cmd-~ sequence. The only way to recover
it is by UNPLUG/PLUG!!!
I don't think this can be called as a FEATURE or ANSI Standard. So, what is
the problem and where is the fix? Anybody has any idea?
Wen
-----------------------------------------------------------------------
main()
{
double x,y;
int i;
x=2;
y=2;
for (i=0; i< 5000000; i++ ) x /= y;
printf("%g\n",x);
}
-----------------------------------------------------------------------bchen@nntp-server.caltech.edu (Bing-Qing Chen) (04/09/91)
In article <1991Apr7.170437.24517@msuinfo.cl.msu.edu> chouw@galaxy.cps.msu.edu (Wen Hwa Chou) writes: >There is nothing fancy in the included small C programs. When compiled as >"cc -o starnge strange.c" everything is OK. But when I tried it as >"cc -O -o strange strange.c" than the Slab is gone - I mean totally gone. >I would not even respond to the cmd-cmd-~ sequence. The only way to recover >it is by UNPLUG/PLUG!!! > >I don't think this can be called as a FEATURE or ANSI Standard. So, what is >the problem and where is the fix? Anybody has any idea? > > ... program deleted ... This appeared to be the same program I posted several months ago. Apparently, there is a floating point operation bug either in the OS or in the 68040. I believe that somebody at NeXT tried the program under 2.1 OS and claimed that it didn't crash the system under 2.1. Hopefully, this is a OS bug instead of 68040 bug. This really has nothing to do with the compiler. With the -O flag, the compiler will generate a very tight loop using register divide instruction fdivx which caused the crash. Bing Chen bchen@pooh.caltech.edu
dwatola@NEXTASY2.EECS.WSU.EDU (David Watola) (04/09/91)
> >There is nothing fancy in the included small C programs. When compiled as >"cc -o starnge strange.c" everything is OK. But when I tried it as >"cc -O -o strange strange.c" than the Slab is gone - I mean totally gone. >I would not even respond to the cmd-cmd-~ sequence. The only way to recover >it is by UNPLUG/PLUG!!! > >I don't think this can be called as a FEATURE or ANSI Standard. So, what is >the problem and where is the fix? Anybody has any idea? > this point has been raised more than once, and has not been satisfactorily addressed. i have looked at the optimized assembly code, and it looks fine. very tight and easy to follow (esp. after you prune the garbage out of the c program--that 'printf' really serves no purpose at all). The unoptimized code is not quite as pithy. i would like to try the assembly code out on another 68040 based machine, but we don't have any others here... yet. i kinda suspect that there may be a bug in the assembler, but i just don't have the time to verify that... does anybody out there have the time and ability to do this? it is a fairly trivial matter to disassemble the code and compare to the .s file, but, hey, i have a thesis to finish up RSN. i know people from next are monitoring this group... it would seem that this would be something they'd be interested in.
madler@nntp-server.caltech.edu (Mark Adler) (04/09/91)
In article <9104090229.AA27828@nextasy2.eecs.wsu.edu> dwatola@NEXTASY2.EECS.WSU.EDU (David Watola) writes: >this point has been raised more than once, and has not been satisfactorily >addressed. i have looked at the optimized assembly code, and it looks fine. (This is in reference to the short code segment discovered by Bing Chen that kills 68040 NeXT's in a major way ...) I had someone at NeXT try that program on a 68040 running version 2.1 of the operating system (with -O), and it did not crash the machine. I will verify this when I get my 2.1 upgrade. The reason 2.1 might be expected to fix this is that 2.1 has new fpu emulation code from Motorola that fixes several bugs in the emulation that comes with 2.0. NeXT mentions two of those, the slow floor() and incorrect tanh() functions, in the 2.1 "fixed" list. They are careful not to mention the much more serious total machine obliteration on intensive numerical computation bug that is manifested in the tight divide loop of that program. NeXT also says that not all 2.0 users need to upgrade to 2.1. An unsupportable statement given this very serious bug which renders any 68040 NeXT a computer that is unable to compute (under 2.0). As in previous postings, I cannot recommend strongly enough that 68040 users should upgrade to 2.1. However you can get it is legal, so long as you are already running 2.0 (there is no license fee to go from 2.0 to 2.1). I suspect that one of the reasons NeXT has this odd attitude about 2.0 is that there is no satisfactory means for OD-only 68040-upgraded cubes to get the 2.1 update. This is just specualtion though ... Mark Adler madler@pooh.caltech.edu
izumi@mindseye.berkeley.edu (Izumi Ohzawa) (04/13/91)
In article <1991Apr9.051123.8923@nntp-server.caltech.edu> madler@nntp-server.caltech.edu (Mark Adler) writes: > >I had someone at NeXT try that program on a 68040 running version 2.1 of >the operating system (with -O), and it did not crash the machine. I will >verify this when I get my 2.1 upgrade. The reason 2.1 might be expected I veryfied that myself just now. The following program, compiled with "cc -O -o strange strange.c" does not crash 040 cube running 2.1. So, upgrade to 2.1. It will fix other things even if you have monochrome station or cube. ---- From a previous posting by: chouw@galaxy.cps.msu.edu (Wen Hwa Chou) >"cc -o starnge strange.c" everything is OK. But when I tried it as >"cc -O -o strange strange.c" than the Slab is gone - I mean totally gone. >I would not even respond to the cmd-cmd-~ sequence. The only way to recover >it is by UNPLUG/PLUG!!! ----------------------------------------------------------------------- main() { double x,y; int i; x=2; y=2; for (i=0; i< 5000000; i++ ) x /= y; printf("%g\n",x); } ----------------------------------------------------------------------- Izumi Ohzawa [ $@Bg_78^=;(J ] USMail: University of California, 360 Minor Hall, Berkeley, CA 94720 Telephone: (415) 642-6440 Fax: (415) 642-3323 Internet: izumi@violet.berkeley.edu NeXTmail: izumi@pinoko.berkeley.edu
madler@nntp-server.caltech.edu (Mark Adler) (04/13/91)
In article <1991Apr12.185839.15689@agate.berkeley.edu> izumi@mindseye.berkeley.edu (Izumi Ohzawa) writes: >In article <1991Apr9.051123.8923@nntp-server.caltech.edu> >madler@nntp-server.caltech.edu (Mark Adler) writes: >> >>I had someone at NeXT try that program on a 68040 running version 2.1 of >>the operating system (with -O), and it did not crash the machine. I will >>verify this when I get my 2.1 upgrade. The reason 2.1 might be expected > >I veryfied that myself just now. Oh frabjous day! Calooh, callay! (he chortled in his joy) >The following program, compiled with >"cc -O -o strange strange.c" does not crash 040 cube running 2.1. >So, upgrade to 2.1. It will fix other things even if >you have monochrome station or cube. Yessiree, don't believe NeXT when they say you don't need to upgrade to 2.1. If you have a 68040, you'd better upgrade. Mark Adler madler@pooh.caltech.edu
wgilbert@watmath.waterloo.edu (William Gilbert) (04/15/91)
In article <1991Apr8.170642.3606@nntp-server.caltech.edu> bchen@nntp-server.caltech.edu (Bing-Qing Chen) writes: >In article <1991Apr7.170437.24517@msuinfo.cl.msu.edu> chouw@galaxy.cps.msu.edu (Wen Hwa Chou) writes: >>There is nothing fancy in the included small C programs. When compiled as >>"cc -o starnge strange.c" everything is OK. But when I tried it as >>"cc -O -o strange strange.c" than the Slab is gone - I mean totally gone. >>I would not even respond to the cmd-cmd-~ sequence. The only way to recover >>it is by UNPLUG/PLUG!!! >> I had a similar problem when I was upgrading my cube and was timing a few of my programs to see the improvement (see a later posting of mine). One of my programs hung the cube when run with the 040 chip. It had run alright with the 030 chip under 2.0. However the program, whether compiled under 1.0a or 2.0 crashed with the 040 chip. After reading this posting I tried turning off the optimization and it ran OK. The program was a modification of one I put on the purdue ftp machine. So BEWARE of Julia.tar.Z (in 1.0 sources). There is only one very special set of parameters I have found that will crash the cube running under 2.0 with an 040 chip; that is when xc=0, yc=0 and Iterates>11. _______________________________________________________________________ Will Gilbert, Pure Math Dept, University of Waterloo, Ontario, Canada wgilbert@math.UWaterloo.ca NeXT mail:wgilbert@fatou.UWaterloo.ca