| Title: | VAX and Alpha VMS |
| Notice: | This is a new VMSnotes, please read note 2.1 |
| Moderator: | VAXAXP::BERNARDO |
| Created: | Wed Jan 22 1997 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 703 |
| Total number of notes: | 3722 |
Crossposted in the DECC 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);
}
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 664.1 | GEMEVN::GLOSSOP | Kent Glossop | Sun Jun 01 1997 18:38 | 27 | |
> DEC C T5.6-001 on OpenVMS Alpha V7.1 and earlier.
Is this really a field test compiler? Have you tried V5.6?
I compiled this with V5.6 and I don't see anything that looks illegal.
I don't have T5.6 or VMS 7.1 so I can't actually run the example.
My *guess* is it is one of two things:
1) [less likely] A new bug in the trap shadow handler in VMS. (Comment -
as stated in ALPHA_SRM note 314, the OS should NOT be doing these
checks in most cases.)
2) There was a point where GEM was generating xor reg, r31, reg in trap
shadows. (This "fancy no-op" is used to get enough spacing between
stores and loads to prevent hardware traps on ev4/ev5/ev56 that
cost performance.) This is legal according to the SRM (it generates
the same value when re-executed), but since some of the OS trap shadow
handlers weren't prepared to deal with it, we temporarily disabled
generation in trap shadows - it will be reenabled in the future.
(The thing that puzzles me is I believe this change was may in mid-1995,
which would have been well before the C 5.6 release cycle.)
Please generate a listing and see if there are any xors between the CVTxx/S
instructions and the final trapb. If there are, then this is probably #2,
otherwise, it's #1. If it is #2, please try this example with the currently
released compiler.
| |||||
| 664.2 | Did you check to see if there are patches available? | GEMEVN::GLOSSOP | Kent Glossop | Sun Jun 01 1997 18:42 | 2 |
Also, does VMS has any patches for the trap handler in 7.1 (since this is showing up in applications)? | |||||
| 664.3 | Don't think it is the compiler. | PEACHS::HAZZARD | Mon Jun 02 1997 00:27 | 37 | |
Yes, the current test was with a field test compiler. However,
Netscape Navigator was built with DECC 5.3 on OpenVMS V6.1. And It has
not been recompiled, but it started failing only on OpenVMS V7.1.
I looked for a patch but didn't see one.
I just tried it with DEC C V5.5-002 on OpenVMS Alpha V7.1, same result,
I don't think it is the compiler. We seen it on several platforms, I've
tested on a 7000, 4000 Model 600, 4000 model 720.
Csc64 $ cc/ver nla0:
DEC C V5.5-002 on OpenVMS Alpha V7.1
Csc64 $ cc/pref=all/float=ieee/ieee=denorm test_ieee
Csc64 $ link test_ieee
Csc64 $ run test_ieee
double value -0.000000
value should be 0
%SYSTEM-F-ILLEGAL_SHADOW, illegal formed trap shadow, Imask=00000000,
Fmask=00000400, summary=03, PC=000000000002013C, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs
PC
TEST_IEEE TEST_IEEE main 1373 000000000000013C
000000000002013C
TEST_IEEE TEST_IEEE __main 0 0000000000000064
0000000000020064
0 FFFFFFFF887BB0D8
FFFFFFFF887BB0D8
I don't see any "fancy no-op". Next reply will be the full listing, from
DECC 5.5 and OpenVMS 7.1.
Thanks
Powell
| |||||
| 664.4 | Full listing for test_ieee.c | PEACHS::HAZZARD | Mon Jun 02 1997 00:27 | 253 | |
Source Listing 1-JUN-1997 21:21:19 DEC C V5.5-002 Page 1
1-JUN-1997 21:09:13 CSC64$DKA400:[P_HAZZARD]TEST_IEEE.C;1
1 /*
2
3 Problems with ILLEGAL_SHADOW trap on OpenVMS V7.1
4
5 How to compile/link:
6
7 $ cc/pref=all/float=ieee/ieee=denorm test_ieee
8 $ link test_ieee
9
10 Output on OpenVMS V6.2
11
12 $ run test_ieee
13 double value -0.000000
14 value should be 0
15 int value 0
16
17 Output on OpenVMS V7.1:
18 $ run test_ieee
19 double value -0.000000
20 value should be 0
21 %SYSTEM-F-ILLEGAL_SHADOW, illegal formed trap shadow, Imask=00000000, Fmask=0000
22 0002, summary=03, PC=0000000000020148, PS=0000001B
23 %TRACE-F-TRACEBACK, symbolic stack dump follows
24 image module routine line rel PC abs PC
25 TEST_IEEE TEST_IEEE main 1413 0000000000000148 0000000000020148
26 TEST_IEEE TEST_IEEE __main 0 0000000000000064 0000000000020064
27 0 FFFFFFFF852B90D8 FFFFFFFF852B90D8
28
29 */
30
31 #include <stdio.h>
703 #include <math.h>
1359
1360 double *dbl;
1361 unsigned unsigned_value[2];
1362 int ret_value;
1363 main()
1364 {
1365
1366 unsigned_value[0] = 1;
1367 unsigned_value[1] = 0x80000000;
1368 dbl = (double *) &unsigned_value[0];
1369 printf("double value %f\n",*dbl);
1370 if (*dbl < 1.0e-307 && *dbl > -1.0e-307)
1371 printf("value should be 0\n");
1372
1373 ret_value = *dbl;
1374 printf("int value %d\n",ret_value);
1375 }
Machine Code Listing 1-JUN-1997 21:21:19 DEC C V5.5-002 Page 2
1-JUN-1997 21:09:13 CSC64$DKA400:[P_HAZZARD]TEST_IEEE.C;1
.PSECT $CODE$, OCTA, PIC, CON, REL, LCL, SHR,-
EXE, NORD, NOWRT
0000 __MAIN::
23DEFFB0 0000 LDA SP, -80(SP)
231F2000 0004 MOV 8192, R24
B77E0000 0008 STQ R27, (SP)
47E13419 000C MOV 9, R25
B7FE0008 0010 STQ R31, __DECC$$HANDLER_DATA_VAR ; R31, 8(SP)
B75E0038 0014 STQ R26, 56(SP)
B45E0040 0018 STQ R2, 64(SP)
B7BE0048 001C STQ FP, 72(SP)
63FF0000 0020 TRAPB
47FE041D 0024 MOV SP, FP
A75B0040 0028 LDQ R26, 64(R27)
23DEFFE0 002C LDA SP, -32(SP)
43A61001 0030 ADDL FP, 48, R1
B7FE0000 0034 STQ R31, (SP)
47FB0402 0038 MOV R27, R2
A77B0048 003C LDQ R27, 72(R27)
43A51016 0040 ADDL FP, 40, R22
B71D0008 0044 STQ R24, __DECC$$HANDLER_DATA_VAR ; R24, 8(FP)
43A41017 0048 ADDL FP, 32, R23
B43E0000 004C STQ R1, (SP)
B6DE0008 0050 STQ R22, 8(SP)
B6FE0010 0054 STQ R23, 16(SP)
6B5A4000 0058 JSR R26, DECC$MAIN ; R26, R26
2362FF90 005C LDA R27, -112(R2)
D340000D 0060 BSR R26, MAIN
A7420030 0064 LDQ R26, 48(R2)
A7620038 0068 LDQ R27, 56(R2)
47E00410 006C MOV R0, R16
47E03419 0070 MOV 1, R25
6B5A4000 0074 JSR R26, DECC$EXIT ; R26, R26
63FF0000 0078 TRAPB
47FD041E 007C MOV FP, SP
A75D0038 0080 LDQ R26, 56(FP)
A45D0040 0084 LDQ R2, 64(FP)
A7BD0048 0088 LDQ FP, 72(FP)
23DE0050 008C LDA SP, 80(SP)
6BFA8001 0090 RET R26
47FF041F 0094 NOP
Routine Size: 152 bytes, Routine Base: $CODE$ + 0000
0098 MAIN::
23DEFFD0 0098 LDA SP, -48(SP)
47E03411 009C MOV 1, R17 ; 001366
B77E0000 00A0 STQ R27, (SP) ; 001363
233F2802 00A4 MOV 10242, R25 ; 001369
B75E0010 00A8 STQ R26, 16(SP) ; 001363
B45E0018 00AC STQ R2, 24(SP)
B47E0020 00B0 STQ R3, 32(SP)
B7BE0028 00B4 STQ FP, 40(SP)
47FE041D 00B8 MOV SP, FP
A43B0020 00BC LDQ R1, 32(R27) ; 001366
A47B0028 00C0 LDQ R3, 40(R27) ; 001368
47FB0402 00C4 MOV R27, R2 ; 001363
Machine Code Listing 1-JUN-1997 21:21:19 DEC C V5.5-002 Page 3
MAIN 1-JUN-1997 21:09:13 CSC64$DKA400:[P_HAZZARD]TEST_IEEE.C;1
A75B0030 00C8 LDQ R26, 48(R27) ; 001369
B2210000 00CC STL R17, (R1) ; 001366
263F8000 00D0 LDAH R17, -32768(R31) ; 001367
B2210004 00D4 STL R17, 4(R1)
43E10000 00D8 SEXTL R1, R0 ; 001368
B0230000 00DC STL R1, (R3)
A43B0040 00E0 LDQ R1, 64(R27) ; 001369
8E200000 00E4 LDT F17, (R0)
A77B0038 00E8 LDQ R27, 56(R27)
40231010 00EC ADDL R1, 24, R16
6B5A4000 00F0 JSR R26, DECC$TXPRINTF ; R26, R26
A0030000 00F4 LDL R0, (R3) ; 001370
8C220048 00F8 LDT F1, 72(R2)
8C000000 00FC LDT F0, (R0)
5801B4CA 0100 CMPTLT/SU F0, F1, F10
63FF0000 0104 TRAPB
8D620068 0108 LDT F11, 104(R2)
C5400008 010C FBEQ F10, L$3
5960B4CC 0110 CMPTLT/SU F11, F0, F12
63FF0000 0114 TRAPB
A7420030 0118 LDQ R26, 48(R2) ; 001371
47E03419 011C MOV 1, R25
A7620038 0120 LDQ R27, 56(R2)
A2020040 0124 LDL R16, 64(R2)
C5800001 0128 FBEQ F12, L$3 ; 001370
6B5A4000 012C JSR R26, DECC$TXPRINTF ; R26, R26 ; 001371
0130 L$3:
A0630000 0130 LDL R3, (R3) ; 001373
8C030000 0134 LDT F0, (R3)
5BE0A5EA 0138 CVTTQ/SVC F0, F10
5FEAA601 013C CVTQL/SV F10, F1
983D0008 0140 STS F1, 8(FP)
A23D0008 0144 LDL R17, 8(FP)
404B1010 0148 ADDL R2, 88, R16 ; 001374
A6420050 014C LDQ R18, 80(R2) ; 001373
63FF0000 0150 TRAPB ; 001373
47E05419 0154 MOV 2, R25 ; 001374
A7420030 0158 LDQ R26, 48(R2)
A7620038 015C LDQ R27, 56(R2)
B2320000 0160 STL R17, RET_VALUE ; R17, (R18) ; 001373
6B5A4000 0164 JSR R26, DECC$TXPRINTF ; R26, R26 ; 001374
47FD041E 0168 MOV FP, SP ; 001375
A75D0010 016C LDQ R26, 16(FP)
A45D0018 0170 LDQ R2, 24(FP)
47E03400 0174 MOV 1, R0
A47D0020 0178 LDQ R3, 32(FP)
A7BD0028 017C LDQ FP, 40(FP)
23DE0030 0180 LDA SP, 48(SP)
6BFA8001 0184 RET R26
Routine Size: 240 bytes, Routine Base: $CODE$ + 0098
.PSECT $LITERAL$, OCTA, PIC, CON, REL, LCL, SHR,-
NOEXE, RD, NOWRT
756C6176 0000 .ASCII \value should be 0\<10><0>\<0>
68732065 0004
Machine Code Listing 1-JUN-1997 21:21:19 DEC C V5.5-002 Page 4
MAIN 1-JUN-1997 21:09:13 CSC64$DKA400:[P_HAZZARD]TEST_IEEE.C;1
646C756F 0008
20656220 000C
000A30 0010
.BYTE 0 [5]
62756F64 0018 .ASCII \double value %f\<10><0>\<0>
0056D170 001C
00000400 0020
00000000 0024
00 0028
.BYTE 0 [1]
.BYTE 0 [6]
.PSECT $LINK$, OCTA, NOPIC, CON, REL, LCL,-
NOSHR, NOEXE, RD, NOWRT
0000 ; Stack-Frame invocation descriptor
Entry point: MAIN
Registers used: R0-R3, R16-R27, FP, F0-F1, F10-F30
Registers saved: R2-R3, FP
Fixed Stack Size: 48
.BYTE 0 [32]
00000000 0020 .ADDRESS UNSIGNED_VALUE
00000000 0028 .ADDRESS DBL
0030 .LINKAGE DECC$TXPRINTF
.BYTE 0 [16]
00000000 0040 .ADDRESS $LITERAL$
2C40C60D 0048 .T_FLOATING 0.100000000000000E-306
0031FA18 004C
00000000 0050 .ADDRESS RET_VALUE
20746E69 0058 .ASCII \int value %d\<10><0>\<0>
00000000 005C
00000000 0060
0000 0064
.BYTE 0 [2]
2C40C60D 0068 .T_FLOATING -0.100000000000000E-306
8031FA18 006C
0070 ; Stack-Frame invocation descriptor
Entry point: __MAIN
Static Handler: DECC$$SHELL_HANDLER
Registers used: R0-R2, R16-R27, FP, F0-F1, F10-F30
Registers saved: R2, FP
Fixed Stack Size: 80
00000000 ; Handler data for DECC$$SHELL_HANDLER000000000000000000000000
.BYTE 0 [48]
00A0 .LINKAGE DECC$EXIT
.BYTE 0 [16]
00B0 .LINKAGE DECC$MAIN
.BYTE 0 [16]
Command Line
------- ----
Source Listing 1-JUN-1997 21:21:19 DEC C V5.5-002 Page 5
1-JUN-1997 21:09:13 CSC64$DKA400:[P_HAZZARD]TEST_IEEE.C;1
CC/LIST/MACHINE TEST_IEEE/IEEE=DENORM/FLOAT=IEEE
These macros are in effect at the start of the compilation.
----- ------ --- -- ------ -- --- ----- -- --- ------------
__VMS_VERSION="V7.1 " __DECC_MODE_RELAXED=1 __vms_version="V7.1 "
VMS_VERSION="V7.1 " __ALPHA=1 _IEEE_FP=1 __Alpha_AXP=1 vms=1
__D_FLOAT=0 __DECC=1 __alpha=1 __32BITS=1 __X_FLOAT=1 VMS=1
vms_version="V7.1 " __IEEE_FLOAT=1 __vms=1 __G_FLOAT=0 CC$gfloat=0
__BIASED_FLT_ROUNDS=2 __DECC_VER=50590002 __INITIAL_POINTER_SIZE=0
__VMS=1 __VMS_VER=70100022 __PRAGMA_ENVIRONMENT=1
| |||||
| 664.5 | Needs an EV4 to reproduce | WIBBIN::NOYCE | Pulling weeds, pickin' stones | Mon Jun 02 1997 09:16 | 44 |
> 21 %SYSTEM-F-ILLEGAL_SHADOW, illegal formed trap shadow, Imask=00000000, Fmask=0000 > 22 0002, summary=03, PC=0000000000020148, PS=0000001B > 23 %TRACE-F-TRACEBACK, symbolic stack dump follows > 24 image module routine line rel PC abs PC > 25 TEST_IEEE TEST_IEEE main 1413 0000000000000148 0000000000020148 > 26 TEST_IEEE TEST_IEEE __main 0 0000000000000064 0000000000020064 > 27 0 FFFFFFFF852B90D8 FFFFFFFF852B90D8 This says that the original trap signaled a "floating invalid" exception, involving an instruction that wrote its result to F1. The trap was delivered before executing the instruction at offset 148. > 0130 L$3: > A0630000 0130 LDL R3, (R3) ; 001373 > 8C030000 0134 LDT F0, (R3) > 5BE0A5EA 0138 CVTTQ/SVC F0, F10 > 5FEAA601 013C CVTQL/SV F10, F1 > 983D0008 0140 STS F1, 8(FP) > A23D0008 0144 LDL R17, 8(FP) > 404B1010 0148 ADDL R2, 88, R16 ; 001374 > A6420050 014C LDQ R18, 80(R2) ; 001373 > 63FF0000 0150 TRAPB ; 001373 Here's the relevant code. (Is this exactly the code that produced the messages above?) I would have expected the CVTTQ/SVC to produce a "floating invalid" trap because its input is a denorm. Alpha hardware doesn't process denorms; it passes them on to the OS to emulate. But that would have produced an Fmask with bit 10 set (00000400), rather than (or in addition to) bit 1 (00000002). And if the CVTTQ/SVC produced an exception, I believe current hardware would have delivered the trap before the CVTQL/SV instruction consumed the result. The register mask seems to say the CVTQL/SV produced an exception. The only exception this instruction can produce is integer overflow. But VMS maps "IEEE integer overflow" to "invalid" -- perhaps that already happens before it handles the /S aspect of the trap? You executed this program on an EV4-based processor (21064, 21066, 21064A, 21066A). EV5-based processors would have reported the trap before the STS instruction. My guess is that VMS is getting upset that the program stores F1 to memory before the trap occurs. There's nothing wrong with this -- VMS shouldn't be checking for that. | |||||
| 664.6 | Trigger instruction is CVTTQ/SVC | STEVEN::hobbs | Steven Hobbs | Mon Jun 02 1997 14:02 | 36 |
I was able to locate a VMS V7.1 system--they are very rare in my
group. When I run the program in .0 I get different exception
parameters. I get:
%SYSTEM-F-ILLEGAL_SHADOW, illegal formed trap shadow, Imask=00000000, Fmask=00000400, summary=03, PC=000000000002013C, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
VAX664 VAX664 main 1343 000000000000013C 000000000002013C
VAX664 VAX664 __main 0 0000000000000064 0000000000020064
0 FFFFFFFF8207B0D8 FFFFFFFF8207B0D8
The code I got when I compiled was:
A0630000 0130 LDL R3, (R3) ; 001343
8C030000 0134 LDT F0, (R3)
5BE0A5EA 0138 CVTTQ/SVC F0, F10
5FEAA601 013C CVTQL/SV F10, F1
983D0008 0140 STS F1, 8(FP)
A23D0008 0144 LDL R17, 8(FP)
404B1010 0148 ADDL R2, 88, R16 ; 001344
A6420050 014C LDQ R18, 80(R2) ; 001343
63FF0000 0150 TRAPB ; 001343
The trigger instruction is the CVTTQ/SVC F0,F10 and the trap pc points
at the very next instruction, CVTQL/SV F10,F1. The instructions
between the trigger instruction and the trap pc make up the trap
shadow so there are no instructions in this particular trap shadow. I
see nothing wrong with any of the code generated by the compiler.
This looks like a bug in VMS 7.1.
Also, the VMS Debugger was unable to display the CVTQL/SV when I did
an EXAMINE/INSTRUCTION. This bug in the debugger was probably caused
because the first several editions of the Alpha SRM did not include
CVTQL/SV in Appendix C. The October 1996 version of the Alpha
Architecture Handbook now includes this instruction in the Appendix.
| |||||
| 664.7 | SKYLAB::FISHER | Gravity: Not just a good idea. It's the law! | Fri Jun 06 1997 11:55 | 4 | |
FYI, I believe I have found this problem...it is a change between V7.0 and V7.1. Powell is checking out a fix now. Burns | |||||