Renesas Technology, M3T-NC308WA, M3T-NC30WA, M3T-NC79WA, M3T-NC77WA, Tool News, 20021001

Tool News


	Tool News
	Products Info
	Downloads
	Tools FAQs

How to print this page

MAEC TOOL NEWS: MAECT-M3T-NC308WA-021001D

Notes on C Compilers M3T-NC308WA, M3T-NC30WA, M3T-NC79WA, and M3T-NC77WA

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 a union declared to be an auto variable
On a switch statement (A)
On a switch statement (B)
On successively referencing the same variable in more than one if statement
On warning option -Wno_used_argument
On directive commands #pragma JSRA and #pragma JSRW

Problem on a Union Declared to Be an Auto Variable
1.1 Product and Version Concerned
M3T-NC308WA V.5.00 Release 1 for the M32C/80 and M16C/80 series of MCUs

1.2 Description
When a member of a union declared to be of strage-class auto is assigned a value, and immediately after the assignment another member of the union is referenced, compiling such a program may results in System Error.

1.3 Conditions
This problem may occur if the following five conditions are satisfied:
(1) Any one or more of the optimizing options -O, -O[1-5], -OR, and -OS are used.
(2) A union containing two or more members whose sizes are different from each other is declared to be of class auto.
(3) To a member, here called member a, of the union in (2) is assigned the result of an operation or the value of a variable.
(4) Immediately after the assignment in (3), another member, b, of the union in (2) is referenced.
(5) Member a takes up smaller amounts of memory space than member b.

Notice:
Even if the above conditions are satisfied, System Error might not be displayed. In such a case, generated code has no problem.

1.4 Example
```
-----------------------------------------------------------------------
   union U {          /* Condition (2) */
       char    a;     /* Condition (5): Member a occupies 1 byte */
       int     b;     /* Condition (5): Member b occupies 2 byte */
   };

   int func(char c)
   {
       union U u;     /* Condition (2) */
       u.a = c;       /* Condition (3): The value of a variable 
                                           assigned to member a */
       return u.b;    /* Condition (4): Member b referenced */
   }
-----------------------------------------------------------------------
```
1.5 Workaround
Immediately after the assignment of a value to member a (Condition 4), place a dummy asm function.
```
-----------------------------------------------------------------------
   int func(char c)
   {
       union U u;
       u.a = c;
       asm();          /* Place a dummy asm function */
       return u.b;
   }
-----------------------------------------------------------------------
```
1.6 Schedule of Fixing the Problem
We plan to fix this problem in our next release.
Top of Page

Notes on C Compilers M3T-NC308WA, M3T-NC30WA, M3T-NC79WA, and M3T-NC77WA
MAECT-M3T-NC308WA-021001D

Problem on switch Statement (A)

2.1 Product and Version Concerned

M3T-NC308WA V.5.00 Release 1 for the M32C/80 and M16C/80 series of MCUs

2.2 Description

When the type of the controlling expression in a switch statement is any of these three, char, signed char, and unsigned char, the code that makes a jump to an incorrect case label may be generated.

2.3 Conditions

This problem occurs if the following three conditions are satisfied:

(1) The type of the controlling expression in a switch statement is any of char, signed char, and unsigned char.

(2) Twelve or more case labels exist in the switch statement in (1).

(3) Compilation generates a table of jump addresses and an indirect jump instruction using the table in the assembly language.

2.4 Example

[Source program in C language]
-----------------------------------------------------------------------
   void func(char c)
   {
       switch (c) {
       case 0:
           ...
-----------------------------------------------------------------------

[Generated code in assembly language]
-----------------------------------------------------------------------
       cmp.b   #00H,R0L       ; As the immediate constant compared with 
       jnc     M2             ; R0L is incorrect, the carry flag is set 
       mov.b   #0dH,R0L       ; to make a jump to the default label.
   M2:
       indexwd.b   R0L
   S1:
       jmpi.w  L31            ; Indirect jump instruction
   L31:
       .word   L3-S1&0ffffH   ; Table of jump addresses
       .word   L3-S1&0ffffH
       .word   L3-S1&0ffffH
          ...
-----------------------------------------------------------------------

2.5 Workaround

Convert the type of the controlling expression in the switch statement to int using the cast operator.

[Example]
-----------------------------------------------------------------------
   int func(char c)
   {
       switch ((int)c) {       /* Cast to type int */
       case 0:
           ...
-----------------------------------------------------------------------

2.6 Schedule of Fixing the Problem

We plan to fix this problem in our next release.

Top of Page

Notes on C Compilers M3T-NC308WA, M3T-NC30WA, M3T-NC79WA, and M3T-NC77WA
MAECT-M3T-NC308WA-021001D

Problem on switch Statement (B)

3.1 Product and Version Concerned

M3T-NC308WA V.5.00 Release 1 for the M32C/80 and M16C/80 series of MCUs

3.2 Description

When three or more case labels whose values are consecutive constants exist in a switch statement, the code that makes a jump to an incorrect case label may be generated.

3.3 Conditions

This problem occurs if the following three conditions are satisfied:

(1) Any one or more of the optimizing options -O, -O[1-5], -OR, and -OS are used.

(2) In a switch statement, a program statement is associated with three or more case labels.

(3) The values of at least three case labels in (2) are consecutive constants.

(4) For the switch statement, compilation generates repetitive pairs of the cmp and jeq instructions in the assembly language.

3.4 Example

[Source program in C language]
-----------------------------------------------------------------------
   int i, j;

   void func(char c)
   {
       switch (c) {
       case 0:
           i = 0;
           break;
       case 1:         /* Condition (3): The consecutive values of 
       case 2:                           case labels, 1, 2, and 3 
       case 3:          */
       case 5:
           i++;        /* Condition (2): The program statement 
                          associated with the above three case labels */
           break;
       case 4:
           i = 1;
           break;
       }
       j = i;
   }
-----------------------------------------------------------------------

In the above example, the switch statement is exited without making the jump to any case label when the value of the controlling expression "c" is 1 or 2.

[Generated code in assembly language]
-----------------------------------------------------------------------
       .glb    $func
   $func:
       cmp.b   #00H,R0L
       jeq     L3          ;  Correct codes are written in the right side.
       cmp.b   #01H,R0L    ;   cmp.b   #01H,R0L
       jeq     L15         ;   jltu    L15
       cmp.b   #03H,R0L    ;   cmp.b   #03H,R0L
       jeq     L17         ;   jleu    L17
   L15:
       cmp.b   #05H,R0L
       jeq     L17
       cmp.b   #04H,R0L
       jeq     L13
       jmp     L1
       ...
-----------------------------------------------------------------------

3.5 Workaround

This problem will be circumvented in either of the following ways:

(1) Rearrange the case labels in order that the values of three case labels might not be consecutive constants.

--------------------------------------------------------------------
   case 1:
   case 2:
   case 5:        /* Move case5 between case2 and case3 */
   case 3:
       i++;
       break;
--------------------------------------------------------------------

(2) Place a dummy asm function to interrupt the continuity of three case labels with consecutive constants.

--------------------------------------------------------------------
   case 1:
   case 2:  asm(); /* Place a dummy asm function (since there is no 
   case 3:            break, the succeeding processing continued */
   case 5:
       i++;
       break;
--------------------------------------------------------------------

3.6 Schedule of Fixing the Problem

We plan to fix this problem in our next release.

Top of Page

Notes on C Compilers M3T-NC308WA, M3T-NC30WA, M3T-NC79WA, and M3T-NC77WA
MAECT-M3T-NC308WA-021001D

On Successively Referencing the Same Variable in More Than One if Statement

4.1 Products and Versions Concerned

M3T-NC308WA V.2.00 Release 1 -- V.5.00 Release 1

M3T-NC30WA V.3.20 Release 1 -- V.5.00 Release 2

M3T-NC79WA V.3.20 Release 1 -- V.4.10 Release 1A

M3T-NC77WA V.5.10 Release 1 -- V.5.20 Release 4

4.2 Description

When two or more if statements contain the same variable, System Error may arise at compilation.

4.3 Conditions

This problem may occur if the following six conditions are satisfied:

(1) Any one or more of the optimizing options -O, -O[1-5], -OR, and -OS are used.

(2) Within if-else constructs, if statements are nested in two or more levels at the else sides. (However, the innermost if statement is allowed to have no else statement.)

(3) The conditional expressions in all the nested if statements in (2) contain the same variable.

(4) After the if-else constructs in (2) exists an if statement whose conditional expression contains the same variable as described in (3).

(5) Before the if statement in (4) exists a program path that does not need to execute the if-else constructs in (2),

(6) Immediately before the if statement in (4) is placed an unconditional jump or a return.

4.4 Examples

[Example 1]
-----------------------------------------------------------------------
   int a, b, cond;

   void func(void)
   {
       if (a == 1) {               /* Condition (5) */
           if (cond > 10) {        /* Conditions (2), (3): 1st nesting */
               b += 1;
           } else if (cond > 5) {  /* Conditions (2), (3): 2nd nesting */
               b += 2;
           } else if (cond > 3) {  /* Conditions (2), (3): 3rd nesting */
               return;             /* Condition (6) */
           }
       }
       if (cond == 1) {            /* Condition (4) */
           b += 3;
       }
   }
-----------------------------------------------------------------------

[Example 2]
-----------------------------------------------------------------------
   int a, b, cond;

   void func(void)
   {
       if (a == 1) {               /* Condition (5) */
           if (cond > 10) {        /* Conditions (2), (3): 1st nesting */
               b += 1;
           } else { 
               if (cond > 5) {     /* Conditions (2), (3): 2nd nesting */
                   b += 2;
               } else {
                   if (cond > 3) { /* Conditions (2), (3): 3rd nesting */
                       b += 3;
                   }
               }
           }
       } else {
           if (a == 2) {
               return;             /* Condition (6) */
           }
       }
       if (cond == 0x0001) {       /* Condition (4) */
           b += 3;
       }

   }
-----------------------------------------------------------------------

4.5 Workaround

Place a dummy asm function immediately before the if statement in (4).

[Example 1 Modified]
-----------------------------------------------------------------------
   int a, b, cond;

   void func(void)
   {
       if (a == 1) {
           if (cond > 10) {
               b += 1;
           } else if (cond > 5) {
               b += 2;
           } else if (cond > 3) {
               return;
           }
       }
       asm();               /* Place a dummy asm function */
       if (cond == 1) {
           b += 3;
       }
   }
-----------------------------------------------------------------------

4.6 Schedule of Fixing the Problem

We plan to fix this problem in our next release.

Top of Page

Notes on C Compilers M3T-NC308WA, M3T-NC30WA, M3T-NC79WA, and M3T-NC77WA
MAECT-M3T-NC308WA-021001D

Problem on Warning Option -Wno_used_argument
5.1 Products and Versions Concerned
M3T-NC308WA V.5.00 Release 1 for the M32C/80 and M16C/80 series of MCUs
M3T-NC30WA V.5.00 Release 2 for the M16C/60, M16C/30, M16C/20, and M16C/10 series of MCUs

5.2 Description
Using warning option -Wno_used_argument(-WNUA) causes a warning message to be displayed for functions that take no arguments. However, generated code has no problem if the message be displayed.

5.3 Conditions
This problem occurs if the following two conditions are satisfied:
(1) Option -Wno_used_argument (-WNUA) is selected.
(2) A function that takes no argument is defined (that is, the processing of the function is described), so it takes void as its parameter.

5.4 Example
```
[Source program a.c in C language]
-----------------------------------------------------------------------
   1   int f(void);
   2   int i;
   3
   4   int f(void)         /* Condition (2) */
   5   {
   6       i = 1;
   7       return 0;
   8   }
-----------------------------------------------------------------------
[Message displayed]
-----------------------------------------------------------------------
   [Warning(ccom):a.c,line 8] function "f()" has no-used argument((null)).
      ===> }
-----------------------------------------------------------------------
```
Note: The line number in the message represents the number of the last line in the function definition.
5.5 Workaround
Neglect this warning since correct code is generated.
Or, the warning can be suppressed in either of the following ways:
(1) Don't use the -Wno_used_argument(-WNUA) option.
Note, however, that this method also suppresses the warning necessary when there are any unused arguments that have already been defined.
(2) Delete the parameter void in the definition of the function (inside the descriptions of the processing of the function).
```
[Example]
--------------------------------------------------------------------
   int f(void);      /* Don't delete this parameter in the 
                        prototype declaration because it is used 
                        for checking arguments at function calls */
   int i;

   int f( /* void */ )      /* Comment out the parameter void here */
   {
       i = 1;
       return 0;
   }
--------------------------------------------------------------------
```
5.6 Schedule of Fixing the Problem
We plan to fix this problem in our next release.
Top of Page

Notes on C Compilers M3T-NC308WA, M3T-NC30WA, M3T-NC79WA, and M3T-NC77WA
MAECT-M3T-NC308WA-021001D
Problem on Directive Commands #pragma JSRA and #pragma JSRW
6.1 Products and Versions Concerned
M3T-NC308WA V.5.00 Release 1 for the M32C/80 and M16C/80 series of MCUs
M3T-NC30WA V.5.00 Release 1 for the M16C/60, M16C/30, M16C/20, and M16C/10 series of MCUs

6.2 Description
Using #pragma JSRA and #pragma PARAMETER or #pragma JSRW and #pragma PARAMETER to declare the same function results in an unnecessary warning message being displayed. However, because both the #pragma directives function properly, generated code has no problem if the message be displayed.

6.3 Conditions
This problem occurs if the following three conditions are satisfied:
(1) #pragma JSRA or #pragma JSRW is used to declare a function.
(2) Then #pragma PARAMETER is used to declare the function in (1).
(3) The function declaration in (2) is made after the function declaration in (1).

6.4 Example
```
[Source file jsra.c in C language]
-----------------------------------------------------------------------
   1   int func(int, int);
   2   #pragma JSRA func               /* Condition (1) */
   3   #pragma PARAMETER func(R0,R1)   /* Conditions (2) and (3) */
   4
   5   int main(void)
   6   {
   7       int i;
   8       i = func(10, 20);
   9       return i;
   10  }
-----------------------------------------------------------------------
[Message displayed]
-----------------------------------------------------------------------
   [Warning(ccom):jsra.c,line 3] #pragma directive conflict
      ===> #pragma PARAMETER func(R0,R1)
-----------------------------------------------------------------------
```
6.5 Workaround
Neglect this warning since correct code is generated. If you want to suppress this warning, place #pragma PARAMETER prior to #pragma JSRA or #pragma JSRW.
```
[Example]
-----------------------------------------------------------------------
   1   int func(int, int);
   2   #pragma PARAMETER func(R0,R1)  /* Place #pragma PARAMETER 
                                            before #pragma JSRA */
   3   #pragma JSRA func
-----------------------------------------------------------------------
```
6.6 Schedule of Fixing the Problem
For M3T-NC308WA, we plan to fix this problem in our next release.
For M3T-NC30WA, the problem has already been fixed in its V.5.00 Release 2.

Top of Page | Pre-Page | Tool News Index


		Close