|
|
The following is a list of all currently known Defects in the current
release of the Code Generation Tools. All defects will be
fixed in the next release unless otherwise indicated.
- Note:
- This list may contain references to internal or beta versions of
the product. So please refer to product availability list to
determine the current production revision.
Date: Fri Sep 27 19:00:00 CDT 1996
Assembler
Linker
Hex Converter
RTS
Documentation
HLL
DEFECTS IN COMPILER V6.60
| Title: COmpiler may gen incorrect code for isolated struct pointer expressions. |
| Bug # | Tool | Version | Fixed? |
| SDSsq01941 | Compiler | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
When generating code to access memory operands of the form "ptr->mos", and
the evaluation of the operands is "isolated", the compiler may err in the
handling of the jump/label tracking. This can result in code with incorrect
control flow (jumping to the wrong place, endless loops, etc.). In this
context, "isolated" means the memory operand is not part of a larger
expression which requires further code to evaluate. Examples include:
struct s
{
int mos;
...
};
struct s *ptr;
volatile struct s *vptr;
...
ptr->mos < 0;
vptr->mos;
Workaround/Solution
WORKAROUND/SOLUTION
===================
Use construct in larger expression or make dummy assignment:
i.e.
if (ptr->mos > 0);
dummy = vptr->mos;
|
| Title: As requested find attached listings for both the working 'C' ... |
| Bug # | Tool | Version | Fixed? |
| SDSsq02023 | Compiler | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
When a nested structure is not the first element within
a structure defnition, the optimizer may inadvertently
calculate incorrect offset for the nested structure
members.
i.e.
typedef struct
{ int mem1, mem2; } LEVEL2
typedef struct
{ int mem3, mem4, mem5;
LEVEL2 nest;
} LEVEL1 ;
void func(void)
{ LEVEL1 *p= (LEVEL1 *) 10000;
p->nest.mem1 = 1000; <====== Incorrect code generated
p->nest.mem2 = 2000; <====== to access these members
Workaround/Solution
WORKAROUND/SOLUTION
===================
1. Make nested structure member first member in parent
structure definition.
i.e.
typedef struct
{ LEVEL2 nest;
int mem3, mem4, mem5;
} LEVEL1;
2. Compile without optimization.
|
| Title: I have experienced the following problem in the C5x C-compiler... |
| Bug # | Tool | Version | Fixed? |
| SDSsq02049 | Compiler | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
The compiler generates a macro for RPTK that is placed at the
beginning of the generated assembly file. If you insert an
asm statement in the C source code that uses the repeat instruction
this gets replaced by the macro and can lead to errors at assemble
time.
i.e. main()
{
asm(" rpt #1");
Results in assembler error
19 0000 0001 rpt #1
********* WARNING - TRAILING OPERAND(S)
Workaround/Solution
WORKAROUND/SOLUTION
===================
Problem will be fixed with next release.
|
| Title: Compiler may gen incorrect code for compare of bit field to power of 2" |
| Bug # | Tool | Version | Fixed? |
| SDSsq02109 | Compiler | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
Given the expression
(s.bf2 & POW2)
where "s.bf2" is a bit field in a structure which is *not* the first member
of that structure, and "POW2" is a power of 2, the compiler generates
incorrect code when such expressions are used for conditional branches.
Conditional branches include "if" statements, "while" and "for" loops,
operands of "&&" and "||", etc. For example:
struct fields
{
unsigned bf1 : 4;
unsigned bf2 : 4;
} s;
...
if (s.bf2 & 8) /* generates incorrect code */
Workaround/Solution
WORKAROUND/SOLUTION
===================
Assign the expression to temporary or change the definition
of the structure to declare that member of the structure first.
|
| Title: I am using register AR7 as global register variable and I use -rAR7.. |
| Bug # | Tool | Version | Fixed? |
| SDSsq02121 | Compiler | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
Using the shell command line option "-rAR6" or "-rAR7" to simply inform the
compiler not to use those registers works fine. However, actually declaring
a global register variable
register int AR7; /* declared at file level scope */
does not work. The compiler incorrectly saves/restores the register in
every function in the file. It should not be modifying the register except
when the user makes a reference to it.
Workaround/Solution
WORKAROUND/SOLUTION
===================
There currently is no workaround for this problem. It
will be fixed in the next release.
|
| Title: Compiler incorrectly restores AR6, AR7 at close of function |
| Bug # | Tool | Version | Fixed? |
| SDSsq02306 | Compiler | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
The compiler errs in generating code to save/restore global
registers AR6/AR7 on entrance/exit from a function even though
these have been declared as register variables. In addition, it
may generate incorrect code when restoring the register values
on exit from the function. Causing incorrect values to be placed
in the register.
Workaround/Solution
WORKAROUND/SOLUTION
===================
None specified at this time. Will fix next release.
|
| Title: Compiler generate incorrect code for access of ioport symbol |
| Bug # | Tool | Version | Fixed? |
| SDSsq02337 | Compiler | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
The compiler "tracks" values in the accumulator, so that it detect cases
where a memory value is already in the accumulator and therefore doesn't
need to be loaded. For example:
a = b + c; /* result ends up in accumulator and 'a' */
d = a; /* instead of loading 'a', copy accumulator to 'd' */
When an assignment from a I/O port is made:
a = port5;
the compiler fails to note that 'a' should no longer be tracked in the accumu-
lator. So, for instance
a = b + c; /* result ends up in accumulator and 'a' */
a = port5; /* 'a' is overwritten, but compiler still tracks 'a' */
/* in the accumulator */
call(a); /* BUG! Instead of loading 'a' from memory, copies */
/* the accumulator to the stack instead */
Workaround/Solution
WORKAROUND/SOLUTION
===================
No workaround available. Problem will be fixed in next release.
|
| Title: The compiler may generate incorrect code for compare of two long vals. |
| Bug # | Tool | Version | Fixed? |
| SDSsq02453 | Compiler | V6.60 | Fixed, will appear in next release. |
Workaround/Solution
WORKAROUND/SOLUTION
===================
Problem will be fixed in next release.
Bug Description
The compiler may err when performing comparing two "long" expressions.
When checking for overflow condition on the results of the compare
it inadvertently resets the oveflow bit, causing incorrect branch
to be taken.
i.e.
long var1,var2;
.
.
if ( var1 > -var2) < incorrect branch may be taken for this
expression
|
| Title: Compiler may core dump when handling comma separated shift expressions.. |
| Bug # | Tool | Version | Fixed? |
| SDSsq02618 | Compiler | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
When handling this expression ...
[memory operand] << [constant expression], [anything]
the compiler may crash. For example:
int i,j;
i<<1, j++;
Workaround/Solution
WORKAROUND/SOLUTION
===================
Compile with optimization.
|
| Title: Code Gen produces internal error on back-to-back assigns with ioports |
| Bug # | Tool | Version | Fixed? |
| SDSsq03246 | Compiler | V6.60 | Will fix in a future release |
Bug Description
BUG DESCRIPTION
===============
The optimizer pass of the compiler may decide to allocate user local variables
to AR registers rather than locations on the stack frame. Similarly, it may
create temporary variables which reside in AR registers rather than memory.
If this circumstance combines with an assignment from a port location,
the compiler doesn't handle it. Instead it emits the internal error message:
COMPILER ERROR: something wrong in port_asg!!!
For example ...
when compiled "dspcl -v2xx -o " has this error.
v2xx -x2 -o3 -op0 -k -s -n file.c
Workaround/Solution
WORKAROUND/SOLUTION
===================
Do not compile with optimization.
|
| Title: Autoincrement of pointer in for loop does not work |
| Bug # | Tool | Version | Fixed? |
| SDSsq03272 | Compiler | V6.60 | Will fix in a future release |
Bug Description
BUG DESCRIPTION
===============
Any time the compiler sees an expression of the form ...
*++ =
and you compile with -v50, the post-increment on the pointer doesn't occur.
The pointer must be to a 16-bit integer type. The bitwise operations are
&=, |=, ^=. So, for example ...
unsigned *p1;
*p1++ &= 0xfffe;
Workaround/Solution
WORKAROUND/SOLUTION
===================
Compile with -v25 -n options to create the assembly file only.
Then assemble with -v50 option. Or increment the pointer in a
separate expression.
|
ASSEMBLER DEFECTS
| Title: C compiler v6.60 is bombing with PASS1/PASS2 OPERAND CONFLICT |
| Bug # | Tool | Version | Fixed? |
| SDSsq02150 | Assembler | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
There is a bug in the handling of the .blong directive when it occurs
near a page boundary. If the value of the current section program
counter, pc, is either xx7d or xx7f when a .blong directive is
encountered, a pass conflict error will occur.
Workaround/Solution
WORKAROUND/SOLUTION
===================
Rearrange the data so that longs will not span a page boundary.
|
LINKER DEFECTS
| Title: Linker gives erroneous message that program space overlaps data space. |
| Bug # | Tool | Version | Fixed? |
| SDSsq01895 | Linker | V6.60 | Will fix in a future release |
Bug Description
BUG DESCRIPTION
===============
When a MEMORY directive defines memory ranges that overlap, the linker
correctly emits an error message, but may err in reporting the names of
the overlapping memory ranges.
Workaround/Solution
WORKAROUND/SOLUTION
===================
Carefully check MEMORY directive in linker command file to
locate overlapping memory ranges, then adjust the lengths
of the offending memory range so that the ranges no longer
overlap.
|
| Title: I am having trouble loading this with the version 6.6 dsp tools... |
| Bug # | Tool | Version | Fixed? |
| SDSsq02003 | Linker | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
V6.60 linker fails to link object code that is the
result of a previous link in which the symbols have
been stripped from the object file. It will give
the fatal error message
"fail to read string table of file ...
Workaround/Solution
WORKAROUND/SOLUTION
===================
The problem is caused by the fact that the because the
symbol table size is zero, the pointer to the start
is interpreted to be the first 4 bytes of the COFF
header. In the string table, the first 4 bytes contain
the size of the table. The linker attempts to read that
many bytes from the file. The workaround therefore is to
increase the size of the object file so it contains at
least that number of bytes.
The simplest method is probably just to append zeroes
to the end ofthe object file until it reaches a size
where the linker error message is not longer given.
|
HEX CONVERTER DEFECTS
| Title: The hex conversion utility does not produce boot header when -v2xx |
| Bug # | Tool | Version | Fixed? |
| SDSsq02847 | Hex Converter | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
The hex conversion utility, DSPHEX, failed to recognize
2xx as valid processor version for generating boot table
and consequently would not generate boot header for COFF
objects generated when -v2xx option is selected for
compile/assemble.
Workaround/Solution
WORKAROUND/SOLUTION
===================
Will be fixed in next release.
|
RTS DEFECTS
| Title: The copy code for .const section will not transfer more than 256 words |
| Bug # | Tool | Version | Fixed? |
| SDSsq02056 | RTS | V6.60 | Fixed, will appear in next release. |
Bug Description
BUG DESCRIPTION
===============
The code for the copy of the .const section within the C boot
routine c_int0, for the C2x and C2xx devices can only copy a maximum
of 256 words. If the length of the .const section is larger than
256 then only the length mod 256 (length % 256) number of items are
transferred.
The problem is caused by use of the RPT to iterate the BLKP
instruction for transferring the data. Since RPT counter register
is only an 8-bit counter on the C2x/C2xx, this restricts the number
of items that can be transferred.
Workaround/Solution
WORKAROUND/SOLUTION
===================
Extract boot.asm from your rts.src:
dspar -x rts.src boot.asm
Perform the following edits. Replace this code:
****************************************************************************
* CONST COPY ROUTINE - COPIES THE .const SECTION FROM PROGRAM TO DATA MEMORY
****************************************************************************
.if CONST_COPY
const_copy:
****************************************************************************
* C2x/C2xx VERSION - MUST USE 'RPT *' BECAUSE RPTK COUNT ISN'T BIG ENOUGH
****************************************************************************
.if .tms32025 | .tms3202xx
LALK #__const_length ; load length of const section
BZ quit ; if 0, quit
LRLK AR2,#__const_run ; AR2 = const address in data
LALK #__const_length-1 ; load length - 1
SACL * ; write to temp
RPT *,AR2 ; repeat length times
BLKP #__const_load,*+ ; block copy from program
LARP AR1 ; restore ARP to SP
quit:
RET ; return
.endif ; .tms32025 | .tms3202xx
With the following code:
****************************************************************************
* CONST COPY ROUTINE - COPIES THE .const SECTION FROM PROGRAM TO DATA MEMORY
****************************************************************************
.if CONST_COPY
const_copy:
****************************************************************************
* C2x/C2xx VERSION - CAN'T USE RPT. COUNTER IS ONLY 8-BITS WIDE
****************************************************************************
.if .tms32025 | .tms3202xx
LARP AR3
LRLK AR3,#__const_length ; AR3 = length of section
BANZ cont,*-,AR2 ; Check for zero and decrement
B quit ; if (zero) quit
cont:
LRLK AR2,#__const_run ; AR2 = const address in data
LALK #__const_load ; ACC = const address in program
cloop:
TBLR *+,AR3 ; copy from program to data
ADDK 1 ; increment program address
BANZ cloop,*-,AR2 ; check for zero and decrement
quit:
LARP AR1 ; restore ARP to SP
RET ; return
.endif ; .tms32025 | .tms3202xx
Assemble the new boot.asm:
dspa -v2xx boot.asm OR dspa -v25 boot.asm
Archive into the object library:
dspar -r rts2xx.lib boot.obj OR dspar -r rts25.lib boot.obj
The C50 is unaffected by this bug. Don't forget the source library:
dspar -r rts.src boot.asm
|
DOCUMENTATION DEFECTS
| Title: There is a bug in the sample program listed on pg 1-26 of the Getting |
| Bug # | Tool | Version | Fixed? |
| SDSsq02490 | Documentation | V6.60 | Will fix in a future release |
Bug Description
BUG DESCRIPTION
===============
The example C program shown on pg 1-26 of the TMS320C1x/2x/2xx/C5x
Code Generation Tools (Release 6.60) Getting Started Guide, shows
incorrect C syntax. This progrma will not compile correctly as written.
e.g.
/*************************************************************/
/* function.c */
/* (Sample file for walkthrough) */
/*************************************************************/
main()
{
int x = -3 <===== Statement missing closing ";"
X = abs_func(X) <===== Statement missing closing ";"
} <===== Note: Symbol "X" should be "x"
int abs_func(int i)
int i; <===== Mix of old K&R and ANSI style func def
{
int temp = i;
if (temp < 0) temp *= -1;
return (temp);
}
Workaround/Solution
WORKAROUND/SOLUTION
===================
A corrected version of the progrma is shown below:
/************************************************/
/* function.c */
/* (Sample file for walkthrough */
/************************************************/
main()
{
int x = -3;
x = abs_func(x);
}
int abs_func(int i)
{
int temp = i;
if (temp < 0) temp *= -1;
return (temp);
}
|
HLL DEFECTS
| Title: The Sun versions of the debuggers, emulators and simulators, do not support |
| Bug # | Tool | Version | Fixed? |
| SDSsq01027 | C2X HLL | V0.00 | Will fix in a future release |
|
| Title: DASM xxx @ PROG/DATA does not update the disassembly window. |
| Bug # | Tool | Version | Fixed? |
| SDSsq00229 | C5X HLL | V2.14 | Will fix in a future release |
|
| Title: Resizing disassembly window crashes the host. For example: |
| Bug # | Tool | Version | Fixed? |
| SDSsq00230 | C5X HLL | V2.14 | Will fix in a future release |
|
| Title: Scrolling diassembly window hangs the debugger. (See Russel Price for |
| Bug # | Tool | Version | Fixed? |
| SDSsq00231 | C5X HLL | V2.14 | Fixed, will appear in next release. |
|
| Title: Disassebler does not correctly show the operands of the following opcodes: |
| Bug # | Tool | Version | Fixed? |
| SDSsq00232 | C5X HLL | V2.14 | Will fix in a future release |
|
| Title: The Sun versions of the debuggers, emulators and simulators, do not support |
| Bug # | Tool | Version | Fixed? |
| SDSsq01142 | C5X HLL | V0.00 | Will fix in a future release |
|
| Title: The OS/2 - version of the emulator does not load source files with |
| Bug # | Tool | Version | Fixed? |
| SDSsq01251 | C5X HLL | V0.00 | Fixed, will appear in next release. |
|
| Title: 1) When using the .def & .ref directives, symbols defined with .set are |
| Bug # | Tool | Version | Fixed? |
| SDSsq01322 | C5X HLL | V0.00 | Will fix in a future release |
|
| Title: An alias command with a string longer than 76 characters causes problems. |
| Bug # | Tool | Version | Fixed? |
| SDSsq01196 | C5X HLL | V0.00 | Will fix in a future release |
|
| Title: When the length of a variable name does not fit completely in the "WATCH" windo |
| Bug # | Tool | Version | Fixed? |
| SDSsq01199 | C5X HLL | V0.00 | Will fix in a future release |
|
| Title: Attempting to watch a variable (WA) that is not defined causes the error |
| Bug # | Tool | Version | Fixed? |
| SDSsq01331 | C5X HLL | V0.00 | Will fix in a future release |
|
|
|