| Some of the registers contain interesting snatches of source code,
including the PC, which resulted in the ACCVIO and stack dump.
R0 = 00000000FFFFFFFF R1 = 000000000000A1C0 R2 = 5B7473696C77656E
"newlist["
R3 = 706128203D205D69 R4 = 6C5F617628203D20 R5 = 00000000000D7890
"i] = (ap" " = (va_l"
R6 = 0000000000658018 R7 = 00000000004B5110 R8 = 00000000005BABE0
R9 = 0000000000000017 R10 = 00000000005BDA40 R11 = 000000007FFCE3E0
R12 = 0000000000000001 R13 = FFFFFFFF82B1BA90 R14 = FFFFFFFF81380900
R15 = 00000000009B0C3C R16 = 000000000075A1CE R17 = 000000002920735F
"_s )"
R18 = 000000007AF1567C R19 = 0000000000007D3B R20 = 0000000000000006
";}"
R21 = 000000007AF134DA R22 = 00000000001797F8 R23 = 000000000000A1C0
R24 = 0000000000000000 R25 = 000000000004BBA0 R26 = 20292B2B69203B74
"t; i++) "
R27 = 00007D3B2920735F R28 = 00007D3B2920735F R29 = 6328282029747369
"_s );}" "_s );}" "ist) ((c"
SP = 000000007AF13510 PC = 20292B2B69203B74 PS = 100000000000001B
"t; i++) "
|
| Hmm, looks like this note got overlooked. The essence of the problem
is that the second invocation of the macro LECS_SYMBOL_LIST, when the
macro L is defined as a block of code with some declarations and a
for loop, expands to a very long line. The /show=expand is encountering
a limit ungracefully when it tries to spread the single macro-expanded
source line over 15 listing lines. If you try to generate a .I file
with the /preprocess qualifier, you get:
%NONAME-W-WRITEERR, error writing NT$:[REPETE.DCB_1272]LECS_SYMBOLS.I;
-RMS-F-RSZ, invalid record size
If you use /preprocess=sys$output to go to your terminal, there is no
error.
Don't yet know exactly what limit(s) is being hit in the listing and
what the fix is.
A workaround is to break the LECS_SYMBOL_LIST macro defined in the
LECS_SYMBOLS.H file into two macros, say LECS_SYMBOL_LIST_1 and
LECS_SYMBOL_LIST_2, and change the invocations of LECS_SYMBOL_LIST
in the .c file to invoke these two macros on separate source lines.
I defined LECS_SYMBOL_LIST_1 to go from L(FSYS_ABORT_FORM) through
L(REPORT_PROGRESS), and LECS_SYMBOL_LIST_2 to go from L(SQLAB2)
through L(VMSMSG), and it compiled fine with /show=expan.
Having a single macro invocation expand without introducing line
breaks is a characterstic of C preprocessing that is common to
all platforms, and we'd be reluctant to change that behavior.
We need to fix the silent ACCVIO in the listing, but the fix might
possibly involve a message saying the expanded line is too long
and suppressing part of it. Is the workaround adequate?
VMS has line length limits that are a little small, but even though
UNIX in principle has no problem with text lines of arbitrary length,
in practice many of the common UNIX text-processing tools have
line length limitations that aren't all that big (e.g. 2K for vi).
So at some point it becomes more practical to break the source code
into smaller pieces than push up the compiler limit.
To answer the question, don't yet know when the bug will be fixed, but
when it is fixed it's possible that you wouldn't be satisfied with
the result unless you change the source in a way that would work
around the bug anyway...
|
| He thanked for the information. He accepts that the addition of a warning
about the output suppression may be the best he could hope for, it's not
a huge headache for them that much at the moment and they haven't found
any other areas where it slows them down.
One other thing which they pointed out was that they tried the same under
VMS 5.5-2 using VAX C 3.2 and that managed to compile cleanly.
The above, I presume is ancient history and unlikely to have any bearing
on this whatsoever.
Neil.
|