Conference turris::decc

2207.0. "issue with ieee and OpenVMS 7.1" by PEACHS::HAZZARD () Sun Jun 01 1997 14:30

    Crossposted in the VMSNOTES conference:

    Hello,

    I'm running into a ieee floating point conversion issue with OpenVMS
    Alpha V7.1.  The attached program works under OpenVMS 6.1 and OpenVMS
    6.2, but fails with an ILLEGAL_SHADOW trap error on V7.1.  I'm seeing
    this with a few IEEE applications,  Netscape Navigator, Java JDK For 
    OpenVMS.  I also noticed where a customer has reported the failure with 
    SoftWindows.

    OpenVMS V7.1 Alpha
    DEC C T5.6-001 on OpenVMS Alpha V7.1 and earlier.

    Any Clues with what changed?

    Thanks

    Powell Hazzard

/*

 Problems with ILLEGAL_SHADOW trap on OpenVMS V7.1

How to compile/link:

$ cc/pref=all/float=ieee/ieee=denorm test_ieee
$ link test_ieee

Output on OpenVMS V6.2

$ run test_ieee
double value -0.000000
value should be 0
int value 0

Output on OpenVMS V7.1:

$ run test_ieee
double value -0.000000
value should be 0
%SYSTEM-F-ILLEGAL_SHADOW, illegal formed trap shadow, Imask=00000000, Fmask=0000
0002, summary=03, PC=0000000000020148, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
 TEST_IEEE  TEST_IEEE  main              1413 0000000000000148 0000000000020148
 TEST_IEEE  TEST_IEEE  __main               0 0000000000000064 0000000000020064
                                            0 FFFFFFFF852B90D8 FFFFFFFF852B90D8

*/

#include <stdio.h>
#include <math.h>

double *dbl;
unsigned unsigned_value[2];
int ret_value;
main()
{

	unsigned_value[0] = 1;
        unsigned_value[1] = 0x80000000;
	dbl = (double *) &unsigned_value[0];
	printf("double value %f\n",*dbl);
	if (*dbl < 1.0e-307 && *dbl > -1.0e-307)
		printf("value should be 0\n");

	ret_value = *dbl;
	printf("int value %d\n",ret_value);
}

    

Compiling and linking on V6.2, no problem running on V6.2.
Take the same .exe and run on V7.1, and your problem reproduces,
and the issue is all within the compiled code.  So it would seem
that what changed must have been the VMS trap handler.

As to whether it's a bug or a feature:

Looking at /list/mach output for the instruction with the "bad"
shadow identified in the traceback (relative PC 0x148):

5BE0A5E1     0144	CVTTQ/SVC F0, F1
5FE1A60A     0148	CVTQL/SV  F1, F10
995D0008     014C	STS	  F10, 8(FP)
A23D0008     0150	LDL	  R17, 8(FP)
404B1010     0154	ADDL	  R2, 88, R16
A6420050     0158	LDQ	  R18, 80(R2)
63FF0000     015C	TRAPB

I'm certainly not an expert on trap shadows, but it's not clear to
me how a handler given an overflow reported at the TRAPB could
determine whether the trigger was the CVTTQ/SVC or the CVTQL/SV.
I'll ask a trap shadow expert to look at this.

The replies there indicate it's a bug (in VMS) rather than a VMS
feature detecting a compiler bug.  I guess the trigger instruction
can be unambiguously identified because the trap handler knows the
result register for the trapping instruction, and the two instructions
in question have different destination registers.

    Thanks for replies.
    
    It does look like a VMS V7.1 issue with something like the trap handler.
    
    Powell