| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2079.1 | Info from ANAL/OBJ | CSC32::B_KNECHT | | Tue Feb 04 1997 08:42 | 42 |
| The customer is very concerned with his production code. He is not
confident with the decc 5.5 compiler and having to recompile some of
the code with decc 5.3 (mentioned in .0 of this note). He has since
performed an ANAL/OBJ on the 5 modules, below is he reply to the CSC
about the ANAL/OBJ information.
Please reply to this note, the customer is getting inpatient and
wants to know more about the LINK-W-TIRLNG messages. THANKS for
your quick reply !
Bob Knecht
Colorado - CSC
*** Message from customer ***
I have inspected the analyze/object output of all five
modules that produce the LINK-W-TIRLNG errors.
In all five cases:
(1) The error message points to the last contribution
to the $LITERAL$ psect from that .OBJ file.
(2) The record in question is indicated as having N bytes,
and contains a "Store Immediate" of M bytes, where
M is greater than N.
(3) The linker error says the overflow is M + 8 bytes.
In the example below,
N = 2049
M = 2217
M + 8 = 2225
It is ironic to note that we have launched into this global
recompile with DECC V5.5 to avoid what appeared to by a more insidious
corruption of the $LITERAL$ psect by the DECC V5.3 compiler;
in that case, there were no errors, but $READONLY$ data
(adjacent to $LITERAL$ psect in same image section) was
corrupted in the image file.
|
| 2079.2 | new, need reproducer | CAIRN::HARRIS | Kevin Harris, dtn 381-2039 | Tue Feb 04 1997 11:20 | 22 |
| Bob,
Sorry to be so late in answering your question. A TIRLNG is always
either a compiler bug or a linker bug. We have not seen a TIRLNG problem in the
field with any DEC C or C++ compiler, as far as I can tell from our records.
Please have the customer provide a test case and get it to us ASAP. It would
be preferable if the test case is small and self contained (no separate headers,
or using a preprocessed file incorporating all the headers used).
In the meantime, to help the customer, the main trick is to find the
source construct that is causing this problem. In fact, I wouldn't be surprised
if the V5.3 and V5.5 problems are both artifacts of the same source construct.
In reducing the test program to a small reproducible case, you or the
customer will likely discover exactly which C construct is causing the problem.
Since it is occurring in 5 modules, it is likely to involve a common header
file, or an interaction with a header and the sources. My guess is that a few
hours work in constructing a minimal test case will allow them to find the
offending source code and provide their own workaround.
We'll have a look at it ourselves as soon as you can provide a
reproducible test case.
-Kevin
|
| 2079.3 | possibly fixed in latest GEM backend | CAIRN::HARRIS | Kevin Harris, dtn 381-2039 | Tue Feb 04 1997 15:09 | 7 |
| I just talked with one of the GEM developers, and she says that this problem
description matches the symptoms that they've seen in other compilers using
the same version of GEM as DEC C V5.3 and V5.5. There have been several recent
bug fixes in this area of GEM that have not yet appeared in a DEC C release,
so when we get an example from the customer, we should be able to say quickly
whether this is already fixed, or is a new problem.
-Kevin
|
| 2079.4 | Thanks! Reproducer requested. | CSC32::J_RABKE | | Wed Feb 05 1997 19:24 | 8 |
|
Thanks, Kevin. I am requesting a reproducer from the customer.
Regards,
Jayna Rabke
CSC/CS
|
| 2079.5 | Criteria for reproducer | CSC32::J_RABKE | | Thu Feb 20 1997 19:51 | 12 |
|
I hate to do this but I have been 'ordered' by my manager to ask
if you would accept the customer's reproducer without reducing
the size of the sample. The reproducer comes in a command file
complete with compile and link commands. The source code is
approximately 500 blocks long. Generally, that is way to large
to send to you but I had to verify it is.
Regretfully,
Jayna Rabke
|
| 2079.6 | Post the location of the reproducer, or mail it | CAIRN::HARRIS | Kevin Harris, dtn 381-2039 | Fri Feb 21 1997 10:37 | 16 |
| > I hate to do this but I have been 'ordered' by my manager to ask
> if you would accept the customer's reproducer without reducing
> the size of the sample.
No harm in asking, the worst we can say is no :-)
> The reproducer comes in a command file
> complete with compile and link commands. The source code is
> approximately 500 blocks long. Generally, that is way to large
> to send to you but I had to verify it is.
In this case, a large reproducer is OK, since it should be pretty obvious from
the resulting object files what source construct is causing the problem. It
will also be easy to test the new version of the backend modules to see if they
fix the problem.
-Kevin
|
| 2079.7 | Reproducer | CSC32::J_RABKE | | Thu Feb 27 1997 14:31 | 18 |
|
Kevin,
Well, actually it depends on who you ask as to how much asking
hurts.
The customer has narowed down the code some about half what it was.
He has provided a command file, BUILD_EXAMPLE.COM, that will create
the object files and execute the LINK. The information to
reproduced the problem is at CSC32""::DISK3:[J_RABKE.TEST].
I really, really appreciate your assistance.
Sincerely,
Jayna Rabke
|
| 2079.8 | Fixed in V5.6 | CXXC::REPETE | Rich Peterson 381-1802 ZKO2-3/N30 | Fri Feb 28 1997 14:58 | 27 |
| The problem occurs in the $LITERAL$ psect in certain cases of
moderately large quantities of literals. In this particular
example, even though the actual source code contains hardly
any literals, the compiler qualifier /check=(uninit) causes
the compiler itself to generate a good-sized section of literal
values used to pre-initialize automatic variables of type
DATUM_TU. This type is a union containing a struct that
is 4k bytes in size, so there is a 4k-byte literal value
used to initialize each such struct. Changing the command
line from /check=(uninit,point=all) to /check=(nouninit,point=all)
makes the problem go away. [Note that uninit is a default value
for the /check qualifier, so if you specify /check at all, you have
to say nouninit explicitly to turn off this feature, just changing
to /check=(point=all) is not sufficient].
While the /check=uninit feature increases the liklihood of encountering
this problem, it can also occur when user code contains significant
constant initializers for automatic variables. A workaround in that
case can be to declare a static const variable of the same type with the
same initializer, and initialize the automatic variable using the
static variable. If the variable is of an array type this will
involve separating the initialization from the declaration, and calling
memcpy() as the first executable statement to copy the static array
into the automatic array.
The underlying problem in the backend has been fixed for the V5.6
compiler.
|
| 2079.9 | Thanks | CSC32::J_RABKE | | Mon Mar 03 1997 14:06 | 9 |
|
Rich,
Thank you for the thorough explanation. We really appreciate
the assistance.
Regards,
Jayna Rabke
|
| 2079.10 | | KERNEL::PULLEY | Come! while living waters flow | Tue May 13 1997 08:14 | 8 |
| Just had a customer who found that the /check=nouninit worked, but when
he declared a static ... =0; and used it in a for loop to init 1500
automatic variables, he still had the problem.
He wondered if the optimisation might have cut out the static
definition and used a constant.
Having closed the call as the nouninit works, I think he perhaps just
didn't init enough automatic variables with static ones.
|
| 2079.11 | | DECCXL::OUELLETTE | mudseason into blackfly season | Tue May 13 1997 14:23 | 4 |
| > perhaps just didn't init enough automatic variables
Perhaps. If we had an example, we could try with a V5.6 compiler.
Though if you want to let sleeping dogs lie, we could do that too.
|