 |
|
|
MAEC TOOL NEWS:
MAECT-M3T-NC308WA_2-011116D
M3T-NC308WA, M3T-NC30WA,
M3T-NC79WA, and M3T-NC77WA
Precautions
|
|---|
Please take note of the following problems in using C compilers (with an assembler and integrated development environment) M3T-NC308WA, M3T-NC30WA, M3T-NC79WA, and M3T-NC77WA:
- On domain errors arising at calling the "pow" function out of the standard library
- On incorrect optimization made in a loop containing a switch statement
- On forced termination of compilation by describing update of a pointer variable within a loop
- On Domain Errors Arising at Calling the "pow" Function out of the Standard Library
- 1.1 Products and Versions Concerned
| M3T-NC308WA | : V.1.00 Release 1 -- V.2.00 Release 2 |
| M3T-NC30WA | : V.1.00 Release 1 -- V.3.20 Release 2 |
| M3T-NC79WA | : V.1.00 Release 1 -- V.3.20 Release 2 |
| M3T-NC77WA | : V.3.20 Release 1 -- V.5.20 Release 4 |
- 1.2 Description
- When a "pow" function is called out of the standard library, a domain error may arise even if values inside the domain are passed as arguments to the function.
- 1.3 Conditions
- This problem occurs if either of the following conditions is satisfied:
- (1) The first argument is zero and the second is positive.
- (2) The first argument is non-zero and the second is negative.
- 1.4 Example
-----------------------------------------------------------------------
#include <math.h>
#include <errno.h>
double ans1;
int func(void)
{
ans1 = pow(0.0, 5.0); /* Condition (1) */
if (errno == EDOM) return -1; /* A domain error evaluated */
return 0;
}
-----------------------------------------------------------------------
- 1.5 Workaround
- Please modify the library source file included with your product, re-create the library, and re-link the user programs.
For details of how to re-create libraries, refer to Article c "Incorporating the Modified Source Program" in Section E.3.2 "Sequence of Modifying I/O Functions" in your User's Manual.
The necessary modification is as follows:
| Whereabouts | : The first if statement in the "pow" function in library source file "pow.c" (about the 5th line from the top of the statement) |
| Modified statement | : if ((x == 0 && y <= 0) || (x < 0 && y != (int)y)) { |
| Original statement | : if (x == 0 || y <= 0 || (x < 0 && y != (int)y)) { |
- 1.6 Schedule of Fixing the Problem
- This problem has already been fixed in the following versions:
- M3T-NC308WA V.3.00 Release 1
- M3T-NC30WA V.4.00 Release 1
- M3T-NC79WA V.4.00 Release 1
- As to M3T-NC77WA, we plan to fix the problem in our next release.
M3T-NC308WA, M3T-NC30WA, M3T-NC79WA, and M3T-NC77WA Precautions
MAECT-M3T-NC308WA_2-011116D
- On Incorrect Optimization Made in a Loop Containing a Switch Statement
- 2.1 Products and Versions Concerned
| M3T-NC308WA | : V.1.00 Release 1 -- V.3.10 Release 3 |
| M3T-NC30WA | : V.2.00 Release 1 -- V.4.00 Release 2 |
| M3T-NC79WA | : V.2.00 Release 1 -- V.4.10 Release 1 |
| M3T-NC77WA | : V.4.00 Release 1 -- V.5.20 Release 4 |
- 2.2 Description
- When a switch statement is described within a loop, optimization may be incorrectly performed at compilation, which moves the whole or part of a series of instructions not to be moved (see Note) into the line immediately before the loop.
- Note: A series of those instructions that describe the operation never performed during the iterative execution of the loop
- 2.3 Conditions
- This problem may occur if the following six conditions are satisfied:
- (1) Optimizing option "-OS" is used at compilation.
- (2) Option "-fST" is selected (only in M3T-NC79WA and M3T-NC77WA).
- (3) A switch statement exists within a for or while statement.
- (4) Any of an auto variable, a register variable, and an argument has been assigned a new value at a case or default label to which the program branches.
- (5) The value stored in the variable or argument in (4) does not change by iterative execution of a loop.
- (6) Compilation generates a series of instructions for indirect branches represented by a branch destination table (see Note) from the switch statement.
- Note:
- A branch destination table is a list of labels representing branch destinations in assembler language corresponding to the case and default labels in a switch statement and is generated immediately after the indirect instructions that reference the table.
If the compiler judges it is efficient to indirectly branch by referencing the branch destination table, it will generate code for doing so. Although whether this judgment is made or not depends on the total number of case labels, the range of their values, and the continuity of the values, these conditions vary with product types.
- 2.4 Example
[C-language source file]
-----------------------------------------------------------------------
int func(void)
{
int i, a, flg = 0; /* The first half of Condition (4): Here,
fig declared to be an auto variable */
for (i = 0; i < 1; i++) {
switch (a) { /* Condition (3) */
case 8:
break;
case 9:
case 10:
case 11:
case 12:
case 13:
case 14:
case 15:
default:
flg = 1; /* Conditions (4) and (5): A series of
instructions corresponding to this
expression moved incorrectly */
break;
}
}
return flg;
}
-----------------------------------------------------------------------
A result of compilation by M3T-NC308WA (a portion)
-----------------------------------------------------------------------
mov.w #0000H,R0 ; i <- i = 0
in the for statement
mov.w -2[FB],R1 ; a
mov.w #0001H,-2[FB] ; flg <- Moved incorrectly
L0: <- The beginning of
iterative execution
sub.w #0008H,R1 ; minimum case
cmp.w #0009H,R1 ; case width check
jnc M2
mov.w #0008H,R1
M2:
indexwd.w R1
S1:
jmpi.w L16
L16: <- The top of the branch
destination table
.word L7-S1&0ffffH
.word L7-S1&0ffffH
.word L7-S1&0ffffH
..............................................................
-----------------------------------------------------------------------
- 2.5 Workaround
- Place a dummy asm function in front of the iterative processing where this symptom occurs.
[Example]
-----------------------------------------------------------------------
for (i = 0; i < 1; i++) {
asm(); /* Dummy asm(); placed */
switch (a) {
case 8:
break;
-----------------------------------------------------------------------
- 2.6 Schedule of Fixing the Problem
- We plan to fix this problem in our next release.
M3T-NC308WA, M3T-NC30WA, M3T-NC79WA, and M3T-NC77WA Precautions
MAECT-M3T-NC308WA_2-011116D
- On Forced Termination of Compilation by Describing Update of a Pointer Variable within a Loop
- 3.1 Products and Versions Concerned
| M3T-NC308WA | : V.1.00 Release 1 -- V.3.10 Release 3 |
| M3T-NC30WA | : V.3.10 Release 1 -- V.4.00 Release 2 |
| M3T-NC79WA | : V.3.10 Release 1 -- V.4.10 Release 1 |
| M3T-NC77WA | : V.5.10 Release 1 -- V.5.20 Release 4 |
- 3.2 Description
- When into the value indirectly referenced by a pointer variable is described a processing that updates the pointer itself, compilation may forcefully be terminated. In such a case, an error message saying "This program has performed an illegal operation. . . ." will be displayed.
- 3.3 Conditions
- This problem may occur if the following four conditions are satisfied:
- (1) The value indirectly referenced by a pointer variable is written into the pointer itself.
- (2) The pointer variable in (1) is assigned to a register.
- (3) In the program exists a for or while statement that uses the pointer described in (1).
- (4) In the for or while statement in (3) resides an invariant expression that could be moved to the outside of the loop if the value in (1) were not indirectly referenced.
- If all the conditions above are met, however, the problem might not arise. In such a case, the code generated is good for use.
- 3.4 Example
-----------------------------------------------------------------------
struct l {
unsigned int no;
struct l *next;
} *pp;
int func(void)
{
register struct l *p = pp; /* Condition (2) */
int i;
int n = 1;
int x = 0;
for (i = 0; i < n-1; i++) { /* Condition (4)
"n-1" is an invariant */
if (p->no > (p->next)->no) x++; /* Condition (3) */
p = p->next; /* Condition (1) */
}
}
-----------------------------------------------------------------------
- 3.5 Workaround
- Place a dummy asm function in front of the iterative processing where this symptom occurs
[Example]
-----------------------------------------------------------------------
for (i = 0; i < n-1; i++) {
asm(); /* Dummy asm(); placed */
if (p->no > (p->next)->no) x++;
-----------------------------------------------------------------------
- 3.6 Schedule of Fixing the Problem
- We plan to fix this problem in our next release.
|
|
