From: cummings@hammer.Prime.COM (Kevin Cummings)
Newsgroups: comp.sys.prime
Subject: Re: A challenge - raise my confidence in Pr1me
Date: 12 Aug 92 19:58:38 GMT
Organization: Prime Computer R&D

In article <9208111615.AA13406@usenet.rpi.edu>, GORMAN_B@prime1.lancashire-poly.ac.uk (Barry Gorman) writes:
> There have been some doubts raised on this list re the continued support of
> Pr1me software. Here is an example of a bug. I challenge Pr1me to fix it and
> to demonstrate on this list that it has been fixed. I'm pretty certain that
> the fault lies in the handling of the exponent in printf(). If you don't
> want to fix it, send me the source, and I will.
> 
> Barry
> .....
> OK, slist testpr.c
> #include <stdio.h>
> main()
>    {int i; double x=1e-6000;
>     x*=1e-3865;
>     for(i=1; i<10; ++i) printf("%e\n", x*i);}
> OK, ci testpr
> [CI Rev. T3.0-23.0 Copyright (c) 1990, Prime Computer, Inc.]
> [Serial #S035-KLR0EC-S89V (East London Polytechnic)]
> 00 Errors and 00 Warnings detected in 5 lines and 184 include lines.
> OK, bind -lo testpr -li c_lib
> [BIND Rev. T3.1-23.0 Copyright (c) 1991, Prime Computer, Inc.]
> [Serial #S037-F1R350-CWD5 (East London Polytechnic)]
> BIND COMPLETE
> OK, r testpr
> 2.003530e+9863
> 4.007060e+9863
> 6.010590e+9863
> 4.000000e-9865
> 5.000000e-9865
> 6.000000e-9865
> 7.000000e-9865
> 8.000000e-9865
> 9.000000e-9865
> OK, stat sys
> 
> System PRIMEE is currently running PRIMOS rev. 23.2.0c
> Copyright (c) Prime Computer, Inc. 1990
> 
> OK, stat hdwr
> 
> Processor type: 9955.
> Microcode revision: Engineering revision 18, Manufacturing revision 9.
> 

PROBLEM SOLVED!  It's actually not a C compiler or C library bug at all.
The problem lies in that veritable PL1 conversion routine called P$ATOA.
(Or as we call it: P $ Any TO Any).  The C library is converting your
floating point data into QUAD format, and there is a bug in P$ATOA while
computing the exponent of a QUAD number during a QUAD to CHARACTER conversion
that does the "excess 128" exponent adjustment in the wrong place, resulting
in the wrong sign for the exponent.  You can very well expect a fix
in T3.3 System Library.  

If you had submitted a SPAR on this problem sooner, you could have had it
fixed in T3.2 (which is in the process of being released to customers
as I write this).  T3.3 could very well be 6-12 months away (ie we have no
ship dates for it yet).

Why does this work with the 22.1 C compiler?  Because that test was done
using CC (the V mode compiler), which does not support QUAD floating point.
QUAD support (long double for you C types) is an ANSI extension and is only
available using the ANSI compiler, which compiles to 32IX mode only.
This P$ATOA bug occurs ONLY while converting QUAD to CHARACTER.  DOUBLE
to CHARACTER does the right thing (therefore CC does the right thing).

I'll be happy to field questions on this topic if you have any.

=================================================================
Kevin J. Cummings                       PrimeService
20 Briarwood Road                       A Computervision Company
Framingham, Mass.                       500 Old Connecticut Path
					Framingham, Mass.
Work:  cummings@primerd.Prime.COM
Home:  cummings@kjc386.framingham.ma.us

Std. Disclaimer: "Mr. McKittrick, after careful consideration,
		  I've come to the conclusion that your new
		  defense system SUCKS..."   --  War Games
=================================================================
Newsgroups: comp.sys.prime