rwolff@noao.UUCP (Richard Wolff) (11/28/84)
The following program (sadly) prints the message
main()
{
int n, i;
float x[2];
x[0] = 1.;
n = 10000;
i = 0;
if(x[i] > n)
printf("finds %g is > %d\n",x[i],n);
}
The relevant assembly code that implements the comparison is
movl -8(fp),r0
cvtld -4(fp),r2
cvtfd -16(fp)[r0],r1
cmpd r1,r2
The selection of "r1" is unfortunate. The section of pcc/table.c
that seems to be at fault is
OPLOG, FORCC,
SAREG|AWD, TFLOAT,
SAREG|AWD, TDOUBLE,
2*NAREG, RESCC,
" cvtfd AL,A1\n cmpd A1,AR\nZP",
Changing A1 to A2 solves the problem. But, is this a correct
solution, and is it the best one?
--
Richard Wolff, National Optical Astronomy Observatories, Tucson, AZ
Usenet: {allegra,arizona,astrovax,decvax,hao,ihnp4} !noao!rwolff
Arpa: noao!rwolff@lbl-csamgwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/30/84)
> The following program (sadly) prints the message > > main() > { > int n, i; > float x[2]; > > x[0] = 1.; > n = 10000; > i = 0; > if(x[i] > n) > printf("finds %g is > %d\n",x[i],n); > } Why not use the current release of PCC instead? That is what I do; I quickly got tired of bugs like this in the one shipped with 4BSD.
ado@elsie.UUCP (Arthur David Olson) (11/30/84)
noao!rwolff-- > The following program (sadly) prints the message... > int n, i; > float x[2]; > > x[0] = 1.; > n = 10000; > i = 0; > if(x[i] > n) > printf("finds %g is > %d\n",x[i],n); brl-tgr!gwyn-- > Why not use the current release of PCC instead? That is what I do; > I quickly got tired of bugs like this in the one shipped with 4BSD. While some folks have the money and clout to keep constantly up-to-date, others do have legitimate economic and legal reasons for using older tools. -- UNIX is an AT&T Bell Laboratories trademark. -- ..decvax!seismo!elsie!ado (301) 496-5688 DEC, VAX and Elsie are Digital Equipment and Borden trademarks
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/01/84)
> > Why not use the current release of PCC instead? That is what I do; > > I quickly got tired of bugs like this in the one shipped with 4BSD. > > While some folks have the money and clout to keep constantly up-to-date, > others do have legitimate economic and legal reasons for using older tools. It doesn't take very many run-ins with the compiler to justify spending the $2500 (MAX) that it would've taken to replace it with a better one. About one reclaimed week of system staff time per year would cover this.