• Important information
• New features
• Known problems
• Program corrections
• User guide corrections
• Miscellaneous
• Release history

Important information

• In version 3.50, the default linker files have been changed so that the -Z directive is used instead of -P for the CSTART segment. This assures that the module order is kept.
• In an application where some global variables are accessed in a large number of locations, these can be declared to be placed in data16 or data13 (bitfields) memory. This is done with the keywords __data16 and __data13 and makes it possible for the compiler to use more powerful instructions such as BNOT, BTST, BSET, etc.
• When using the Huge or Far data model and Embedded C++, only huge or far variable data and constant pointers are allowed. This means that the memory models cannot be mixed when the Enable Embedded C++ syntax option is selected.
• The IEEE-695 output format implementation does not support the use of C++ identifiers. For this purpose, use UBROF or ELF/Dwarf. The latter is also the C++ debug format supported by the Renesas debugger.
• Please read the following migration information if you are planning to migrate from V1.x or V2.x of the product.

New features

• None

Known Problems

• EW22002/EWM16C-454
  A while loop with a preincrement or predecrement in the loop test could be optimized incorrectly if the final part of the loop body was a do loop. Example:

          while ( (--count) >= 0) 
          { ...
            i = 7;
            do 
            { ... 
            } while( i-- );
          }
          

• EW21133
  The compiler issues the MISRA-C:2004 error 5.1 for internal preprocessor symbols longer than 31 characters.
• EW18233
  The << operator might emit an error message for the far/huge data models. Example:
  myString << myFloat ;
  Workaround:
  1) myString.operator << (myFloat ) ;
  2) static_cast<ostream &>(myString) << myFloat ;
• EW14409
  If you use the option --hp_debug, indexing a local struct greater than 128 bytes gives an incorrect result and assignments to its elements will fail.

Program Corrections

• EWM16C-458
  When you are using the memcpy function and constant data is set to far and the source address is a constant expression, for example a variable placed with the @ operator, the source address will be wrong.
• EWM16C-460
  Large loops with a loop counter that counts downward toward zero can generate an internal error on optimization level High. Note that the compiler can reverse some loops that count upward, which in turn can result in this behavior.
• EWM16C-456
  If one of the intrinsic functions __RMPA_W_overflow or __RMPA_B_overflow is used, the linker will produce a warning.
• EWM16C-461
  Using the intrinsic function __BTSTS on optimization level High causes an internal error.
• TPB-2102
  Pointer arithmetics could be incorrectly optimized in loops with a test at the end of the loop body, if the loop variable was smaller than the pointer's index type and it was decremented in the loop body.
• TPB-2335
  On optimization level High, a variable (v) can be optimized incorrectly if v is incremented with a constant value inside a do loop, the do loop has a computable trip count, the do loop is surrounded by another loop with a computable trip count, and v is not used inside either of the two loops, except for the increment.
• TPB-2336
  An indirect postincrement of the result of a postincrement ( (*p+)+ ), is not handled correctly.

User guide corrections

• New data type attribute __no_bit_access
  Description: Inhibits the use of bit instructions when accessing individual bits of an object.

• Section "Type qualifiers", "Rules for accesses"
  In the IAR C/C++ Compiler for M16C/R8C, accesses to volatile declared objects are subject to these rules:
  
  -All accesses are preserved
  -All accesses are complete, that is, the whole object is accessed
  -All accesses are performed in the same order as given in the abstract machine
  -All accesses are atomic, that is, they cannot be interrupted.
  
  The compiler adheres to these rules for all 8-bit data types. Variables declared volatile and __data13 can be accessed using bit access unless they are also declared __no_bit_access.

• New optimization option
  Syntax: --aggressive_inlining
  Description: Use this option to inline larger functions at the optimization levels High balanced and High speed.

• #pragma constseg limitation
  The pragma directive #pragma constseg does not work in combination with variables declared as __no_init. Therefore, use the @ operator or the #pragma location directive instead.

• EW26338/EWM16C-457
  The compiler guide description for #pragma dataseg is mentioning constseg instead of dataseg in section Descriptions of pragma directives.

Miscellaneous

• None

Release history

3.70.1, October 2014

Program corrections

• EW24688
  When you make a combination of a bitwise and (&) and bitwise not (~) on a character object and the bitwise and operator is exactly one bit wide, incorrect code can be generated.

3.60.1, June 2010

3.50.3, December 2012

Program corrections

• EW23407
  Shift expressions with 64-bit variables with a variable shift count could in some cases corrupt the shift count variable and subsequent uses of that variable could be erroneous.

New features

• New data type attribute __no_bit_access
  The new data type attribute __no_bit_access inhibits the use of bit instructions when accessing individual bits of an object.

3.50.2, May 2012

Program corrections

• EW23106
  An error in the bit handling could in rare cases cause the BNOT instruction to be used where BNTST was expected.
• EW22245
  An internal error is no longer generated for the character '?' (code 0xff) when multibyte support is used.

3.50.1, November 2010

New features

• Long long support
  The compiler now supports 64-bit integer types.
• A new optimization option, --aggressive_inlining, has been added
  See description under "User guide corrections" below.

Program corrections

• EW22001
  Debug information for local variables placed on the stack, including function parameters, are now correct for monitor fuctions.
• EW21828
  Calculations on far pointers on the form ptr[i-constant] now return a correct address.
• EW21824
  The compiler optimized an instruction sequence with an ADD and an JNZ instruction by replacing it with an ADJNZ instruction, but for negative constants this is incorrect if the constant is smaller than -8. This has been corrected.
• EW21733
  Function inlining combined with bit handling no longer leads to incorrect optimizations.
• EW21639
  Stepping out from an interrupt function in a debugger did not work because the debug information was incorrect. This has been corrected.
• EW21212
  Register numbers for debug information were incorrect, which could lead to erronous variable information in the IEEE695 output format. This has been corrected.
• EW22021
  If the value of a parameter passed by constructor (needing a constructor and passed by value) was used on the right-hand side of an assignment, incorrect code could be generated in some memory models.

3.40.5, October 2009

Program corrections

• EW21337
  Combinations of multiple comparisons or subtractions and right shifts could yield too aggressive optimizations.
• EW21333
  Using C++ for the Near data model with writable constants, the table for destruction of static objects was placed in segment DATA16_C instead of DATA16_I and DATA16_ID.
• EW21228
  If you had a multiplication on two unsigned char variables that both were casted to signed (short) integers, the multiplication would be on sign extended characters instead of zero extended characters.

3.40.3, August 2009

• EW21279
  The compiler generated unexpected errors when using the command line options --misrac2004 and --misrac1998.

3.40.2, August 2009

• EW21222
  For certain source code examples and on high optimization levels, the compiler hanged and newer finished the compilation.

3.40, July 2009

New features

• MISRA-C:2004 support
  IAR Embedded Workbench now supports automatic checking of source code for conformance to the MISRA-C:2004 standard.

Program corrections

• EW21006
  The compiler no longer fails to generate UBROF object format information for a preprocessor symbol that has a value longer than 65535 characters.
• EW20911
  When using --variable_data=huge or far and 64-bit doubles, some expressions using static or global variables generated internal errors.
• EW20811
  The topics System startup and termination and Customizing cstartup.s34 were missing from the C/C++ Compiler Reference Guide.
• EW20774
  Multiplications that invoked the 16bit x 16bit => 32-bit multiplication sometimes were incorrectly signed/unsigned due to discarding significant casts.
• EW20408
  Empty while() loops should no longer cause an internal error.

3.30D, January 2009

• EW20775
  When using 64-bit doubles while placing constants in far (or data20) memory, some arithmetic operations could place compiler generated constants in DATA16_C memory instead.
• EW20223
  In some cases a volatile access to a bitfield wider than one bit could erroneously be executed as a single-bit access.
• EW20683
  When you try to print a 64-bit double with a value less than 1.0 with the printf library function the program will halt in an infinite loop, due to an incorrect optimization.
• EW20682
  When trying to print a 64-bit double using the library function printf with modifier %e (or %E), the exponent was omitted.

3.30A, June 2008

• EW19920
  On high optimization level (-s9/-z9) if you called a function between occurences of a global or a static variable, and the function manipulated that variable, the second access of that variable could incorrectly be removed.
• EW19919
  Declaring a class-specific two-operand operator delete in a class template could cause the compiler to crash.
• EW19876
  When accessing a struct or array on a constant address and using the far data model, the member address calculation could be incorrect if the constant address was above 0x7fff.
• EW19765
  Due to an optimizer problem, assigning a value cast from unsigned int to unsigned char to a struct member when #pragma pack (1) was used, could go wrong.
• EW19717
  Longer jumps are now used in subroutine calls between different modules in the assembler library because the one previously used could be too short in some cases.
• EW19683
  If the last line in the source code was a #line directive, and there were previous #line directives, the compiler could crash when producing a compiler list file.
• EW19756
  When generating output in the UBROF format and using the no local symbols option (-n{c}), XLINK generated a file that would cause C-SPY to terminate if the debug information referred to a local symbol (like a static function).
• EW19564
  On the highest optimization level, the internal error [CoreUtil/General]: Node following outline call point is not interprocedural, could in rare cases be generated.
• EW18936
  The exp() function in 64-bit mode did not compute the correct value for arguments larger than +/-88.

3.21F, December 2007 (Update)

EW19658
When accessing single bits in __data13 variables, poorly optimized code and in certain cases also erronous code was generated.

EW19597
When calling a function with a small struct or union as parameter with uneven size as well as subsequent other parameters on the stack, the stack would errounously be aligned for those other parameters. This only happened with option --align_data=2.

3.21D, June 2007 (Update)

• EW19049
  When using arrays of function pointers, the compiler generated the wrong addressing mode when the index expression to the array contained a negative constant.
  Example:
  arrayOfFunctions[var-1]();

3.21C, May 2007 (Update)

• EW19099, EW19100
  SHA instructions could erroneously be optimized away at high optimization levels.

EW18876
On high optimization the result from the intrinsic function __RMPA_W could be optimized away.

EW18874
Bit variable assignments could be erronous at high optimization levels.
Example:
bit_variable = other_bit_variable;

EW18862
Compiler list files including any instruction using the dsp8[FB] addressing mode with negative offset, were not show correctly. Instead of -0x05 it showed -0x105. The resulting code was accurate but required a few more bytes than necessary.

3.21B, February 2007 (Update)

• EW18762
  In rare cases non trivial far pointer expressions which results in a constant:20[Ax] addressing mode would get an erronous large negative constant.

3.21A, December 2006

• EW18198
  In a case where:
  1. you were using more than one array expression
  2. the index in these expressions was the same
  3. the index was a member of a global or static struct
  4. the index was updated between the accesses
  the updating of the index variable could be optimized away on high optimization levels.
• EW18141
  When you had a function that took an odd-sized struct as a parameter, subsequent parameters and local variables could be accessed with the wrong offset. This only occured when data alignment was set to 2.
• EW18454
  Debug info for PUSHM and POPM was broken which could lead to instructions being erroneously optimized away after a POPM instruction.
• EW18415
  When assigning a __data13 pointer to an integer and that integer was subsequently used at least two times, the assignment could be corrupted.
  Example:
  tempinteger = &a_data13_ptr;
  otherval[0] = (unsigned char)tempinteger & 0xFF;
  otherval[1] = (unsigned char)(tempinteger >> 0x8) & 0xFF;
• EW18401
  The compiler removed some inline assembler instructions during optimization which is not correct.
• EW18458
  For a negated unsigned variable in a division expression, faulty code could be generated at optimization level -s9 and -z9.
  Example:
  unsigned char u;
  -u/123;

3.20D, October 2006 (Update)

• EW18262
  When doing an assignment from a volatile and absolute located variable where the assigned value is not used, the assignment could be optimized away.
  Example:
  __no_init volatile int volatile_var @ 0x3AE;
  
  int f(void)
  {
  int i;
  i = volatile_var;
  i = 1;
  return i;
  }
• EW18239
  If you had two (or more) consequtive PUSH.W instructions that were combined to a PUSHM instruction and they were later followed by the corresponding POP.W or POPM instruction then, other instructions could be removed after the POP instruction due to erroneous content information in the optimizer.
• EW18199
  When having an object on the stack larger than two bytes, it was accessed two (or more) times. Any access to that object following the first, could have an invalid offset.

3.20C, June 2006 (update)

EW18056
Copying structs in the Data20 or Far data memory model could in some cases destroy the pointer to the source making subsequent accesses to that pointer erroneous.

EW18084
When using absolute located volatile variables, the volatile keyword could in some instances be ignored.

EW18099
When testing on a volatile variable, most notably bitfields, the test was in some cases erroneously removed on the optimization level high.

EW18125
Any use of the instruction MUL(U).B <any src>, A0 (obviously used in char variable multiplication) by the compiler, erroneously removed earlier instructions that used A1 as destination. This only occured on optimization level high.
Example, given a sequence like:
MOV.W #1, A1
MUL.B #4,A0
the compiler would remove the MOV instruction

3.20B, April 2006 (update)

EW17995
When using an array placed in far memory, indexing could go wrong. Additional requirements for this error to occur was that the array had to be static or global and that the indexing expression had to contain a negated, unsigned variable.

EW17015
The compiler failed to calculate a correct array index if the index expression included a constant expression. This error was solved only partly in version 3.20A.

3.20A, March 2006

EW17731
Having a signed operand while using size optimization, shift failed in that a shift logical (SHL) instruction was generated instead of a shift arithmetic (SHA).

EW17664
Due to an optimization error, if code between a jump and it's destination was removed by the linker, you would end up with a JMP.S to the next instruction which resulted in a range error.

EW17657
For a multiplication expression where two 16-bit expressions casted to 32-bit where multiplied, this multiplication could destroy one of the expressions prior to the multiplication.

EW17615
When the optimizer tried to apply the algorithm for Constant folding, an internal error was in rare cases generated.

EW17349
When a __far array was used, the index calculation went wrong if the index expression contained a negative constant.

EW17315
When using the Word align function entries option, byte gaps between functions were padded with 0x00, which for the M16C is the BRK instruction. Now, NOP is used instead.

EW17022
On the highest optimization level, an internal error could in rare cases be generated for C++ code and memory model Far or Huge.

EW17015
The compiler failed to calculate a correct array index if the index expression included a constant expression.

EW16928
At optimization level -z9 and -s9, bit-move instructions could incorrectly be removed when the __bitvar keyword was used.

EW16786
For addition and subtraction on absolutely located __far pointers, the compiler calculated a wrong resulting address.

EW16677
Any shift on a 32-bit value with a variable shiftcount, where the variable is located in a register, would destroy the shiftcount variable.

EW16619
On a high optimization level any generated MUL or MULU instruction could destroy the high register of the destination without restoring it afterwards.

EW16530
A call to the intrinsic function memcpy generated a Coloring failed error whenever the source argument was a far pointer resulting from an array index or structure offset calculation.

EW14944
For statements that consisted of only a volatile variable, the volatile keyword was not acknowledged and the access was optimized away.

3.10B, May 2005 (patch)

EW16786
For addition and subtraction on absolute located __far pointers, the compiler calculated wrong resulting address.

EW16677
Any shift on a 32-bit value with a variable shiftcount, where the variable is located in a register, would destroy the shiftcount variable.

EW16619, EW16837
On high optimzation any generated MUL or MULU instruction could destroy the high register of the destination without restoring it afterwards.

EW16391
An error occurred when a local variable was used as shift distance in a shift expression and thereafter used further in the program. Example:
void main (void)
{
char a=1, b=1;
a >> b;
b++; //b is now corrupt
}

3.10A, December 2004

EW15090
The register preserving correction made earlier for the library function ?GENERIC_MOVE_LONG was not complete. This has now been corrected.

EW14744, EW14745
The %i and %X formatting specifiers did not work in the HUGE memory model.

EW14798
The intrinsic function __no_operation() was not working.

EW14810
When accessing a volatile variable which was located at addresses above 64Kbytes and the result was not needed, the compiler sometimes generated code that gave a range error during link time.

EW15777
The code motion optimization sometimes triggered an unhandled exception when compiling with -s9 or -z9.

EW14925
The DLIB HEAP did not work correctly outside the first 64Kbytes of the memory.

EW15474
At highest optimization level, the compiler optimized away the actual shift instruction for an expression like:
signed int i = ( 0x1<< 9 ) ;

2.12F, November 2004 (Patch)

EW15900
Left shifts with constant could for some constants lead to erronous code being generated when optimizing for speed.

2.12E, July 2004 (Patch)

EW15633
For functions that have a pointer as return value (returning struct/union or double), the compiler was likely to optimize away the code that sets this return pointer up.

2.12B, April 2004 (Patch)

EW15246, EW15274
Floating point compare could generate wrong results due to incorrect optimization. This happened frequently when comparing with constants.

EW15090
In some cases the compiler assumed that the content of registers R3:R1 was preserved when calling the library function ?GENERIC_MOVE_LONG even though the value was destroyed.

EW14957
__set_interrupt_level() used with a variable argument could result in an incorrect interrupt level being set.

EW14828
A __regbank_interrupt function went corrupt if it contained a function call just before returning.

EW14781
Code like:
__set_interrupt_level(currentInterruptLevel);
Where currentInterruptLevel is an unsigned char that has been set previously by a call to __get_interrupt_level(), gave an internal error.

EW14755
Whenever a JSR instruction is immediately followed by an RTS instruction, the two instructions are replaced by a single JMP instruction by the optimizer. This happens when a function call is the last statement in a byte aligned (-u1) function. This is called tail calling. If the calling function and the called function had a short (less than 8 bytes) function between them and the intermediate function was never called, the linker would emit a range error. This was because the intermediate function allowed the tail calling JMP instruction to be a JMP.S instruction but because the intermediate function disappears at link time, since it is never called, the destination of the JMP.S instruction became the following instruction and that is not allowed for JMP.S.

EW14734
JSR.W instruction was used for all calls to funtions residing in the same source code file. This is not correct when the called function is placed in another segment.

EW14730
The symbols:
__CONSTANT_DATA_NEAR__
__CONSTANT_DATA_FAR__
__CONSTANT_DATA_HUGE__
were not predefined as they should have been.

EW14684, EW14938, EW14869
When byte alignment was used and a function ended with a call to another function, an internal error sometimes appeared.

2.12A, November 2003

• EW14562
  The IAR C Library ptrdiff_t was wrongly assigned an unsigned integer type. Now it is either signed int or signed long.
• EW14656
  A complex test expression consisting of several tests of bits in the same variable and both the operators || and &&, could some times be simplified (optimized) incorrectly. Example:
  
  if (((x & 1) || (x & 2)) && ((x & 4) || (x & 8))) ...
• EW14647
  Malloc returned the same pointer value for sub-sequent calls.
• EW13907, EW13881
  In some cases, complex pointer arithmetics like below, could cause a compiler error:
  
  *(txBuffer + txBuffer[0]++ - 1) = '.';
• EW14567
  Assignments to members of a bitfield struct could in rare cases modify the value of other members of the struct as well.
• EW14436
  When using local variables in an interrupt function, the compiler could generate an incorrect error message if the alignment was set to 2 (default).
• EW14427
  The __data13 keyword was used for SFR port register declarations. This caused the compiler to generate read-modify-write operations for these, that are not allowed.
• EW14419
  Debug information for local variables was not correctly generated for the Elf/Dwarf output format.
• EW14410
  Shifts with constant could for some constants lead to incorrect code being generated.
• EW14408
  Functions compiled with --hp_debug and alignment=2, which did not contain any stack variables, would corrupt the stack frame.
• EW14237
  Long variables located in register pair, for example A1A0, R2R0, or R3R1 could get erronous values in all debug formats except UBROF 9 and ELF/Dwarf, since these registers had incorrect register numbers.
• EW14235
  Some code constructions with data the model "near" and constants in "huge" memory, could give a range error in the linker.
• EW14197
  The "__tiny_func" keyword did not work due to that the JSRS expression was incorrectly evaluated.

2.11A, July 2003

• EW14161
  Some SFRs contains "Nothing is assigned"-bits. The compiler could erronously generate code that wrote "1" to such bits, which is not allowed.
• EW14028
  The intrinsic functions __get_interrupt_state and __get_interrupt_level would sometimes generate an internal error when the return value from the functions were assigned to a local variable.
• EW14008
  When assigning 0 to a __bitvar variable, an internal error occurred.
• EW13994
  In some cases, incorrect output or erronous code was generated for floating point values with sprintf.
• EW13929
  The intrinsic function __set_INTB_register(unsigned long) did not work and generated an internal error.
• EW13790, EW14066, EW14026, EW13984
  Shifts with constant could for some constants lead to erronous code being generated. This could also happen on division by N, where N=2^X.
• EW13733, EW13928
  The compiler sometimes optimized away the highword of a __data20 object address if it was located above 0xFFFF.
• EW13718, EW13635
  The compiler produced incorrect type information when compiling a file which contained a struct, one of whose fields was a pointer to another struct, and where the first struct was used in a context where its size or any offsets into it were not needed. The type information for the second struct was incorrect, which could lead to numerous incorrect type conflict warnings when linking.
• EW13676
  For the __SMOVF_B intrinsic function, the source address was sometimes corrupted before the instruction was executed.
• EW13675
  When comparing two 32-bit values the compiler generates a call to a compiler internal library function ?F_CMP_L04. The subroutine was erronous and would most likely return to an unknown address.
• EW13656
  For interrupt functions, the exit code sequence was emitted by the compiler even though no framepointer was needed.
• EW13642
  The compiler option --code_segment / -R did not work.
• EW13633
  When copying memory using long pointers, the last copy in a sequence could erronously be optimized away.
• EW13976
  Interrupt symbols were missing in several headerfiles

2.10A, February 2003

• EW13073, EW12652
  Preprocessor directives are not allowed in in-line assembler, but an internal error was erroneously generated instead of a syntax error.
• EW13052
  An error was not generated for constructions like:
  
  int const *pci = 0; pi = &pci[0];
• EW12601
  When using a local optimization level (with #pragma) higher than the applied global optimization level, an internal error was generated.
• EW13005
  The preprocessor could generate incorrect float values due to incorrect rounding. Example:
  #define R ((the correct unsigned char)(40.1 - 25.1))
  #define W ((unsigned char)(40.01 - 25.01))
  
  where R would have value 15, but W would have the incorrect value 14
• EW12764
  An internal error was generated for a comparison between two 64-bit FP values (pointed to).
• EW12561, EW12986
  When compiling a module using byte aligned objects and having calls to functions compiled with word alignment, you could get erroneous results due to different parameter placement on the stack. This is corrected by not allowing modules with different alignment to be linked together. Runtime libraries for both 1- and 2-byte alignment are supplied.
• EW12364, EW13407
  The library functions GENERIC_MOVE_LONG_L08 and F_CMP_L04 did erroneously not preserve registers R2R0.
• EW12121
  Due to an optimizer error, the following code generated an internal error:
  
  unsigned int i;
  void (*aPf[500])(void);
  void main(void)
  {
  aPf[i,i]();
  }
• EW11859
  A struct type where only the tag has been declared will have 0 as pointer value. The compiler could earlier not recognize pointers to different tag-only declared structures.
• EW11800
  Using intrinsic functions with incorrect declarations could sometimes generate an internal error.
• M16CC0148, EW11702
  The expression below (where b and c unions) generated an internal error (Illegal event in extra_clist_for_asg).
  a.f1.byte |= (b.f1.byte & (~c.f1.byte) & (~ 0xF1 ));
• EW10188, CFE0088
  The volatile attribute in pointers to volatile objects was not considered when making the actual object code.
• M16CC0130
  When an operand of >= was implicitly converted to a 64-bit double, an error occurred.
• M16CC0136, M16CC0137
  Compound statements using 64-bit doubles could lead to an internal error in the compiler.
• CFE0100
  The preprocessor modified #include lines if they contained names previously defined by #define. Example:
  
  #define name "name"
  #include <name.h>
  
  leads to that
  
  #include <name.h> becomes #include <"name".h>
• M16CC0118, CFE0021
  The extra parenthesis (that should not affect the evaluation) in the expression below caused the compiler to incorrectly evaluate the if statement as false
  
  if (a || (b || (c && d)) || e)
  printf("OK\n");
  else
  printf("Bug\n");
• M16CC0093, CFE0087
  For a declaration: volatile char arr[20];, the expression &arr dropped the volatile attribute.
• G0066
  Very large basic blocks with lots of assignments to static or dynamic objects used a lot of memory. Compiling files with such code could take very long time.
• M16CC0077, CFE0072
  Code with #ifndef without matching #endif is accepted without any errors or warnings.
• M16CC0053, G0027, CFE0015
  An internal error (wild case X06) was generated for some types of nested dummy switches.
• M16CC0091,G0058
  Assignment to the first element in volatile arrays, unions, and structures generated an internal error in some cases where the r value (the expression to the right of the assignment operator) was not a simple variable.
• M16CC0104
  Cross-referencing of structs could generate compiler errors like:
  Error[64]: Unknown size of variable object 'struct1'
  Error[58]: Identifier 'struct1' redefined

1.36A, April 2002

• EW10784, M16CC0141, M16CC0142
  Using #pragma memory interferes with the placing of far const objects in the FAR_CONST segment. When compiling files using #pragma memory, make sure that the NO_FAR_CONST environment variable is set. This will disable the placement of far const objects in the FAR_CONST segment.
• EW11677
  Comparing address expressions with the mixed memory model could in some cases generate an internal error (label_trees_C03: Illegal state).
  Example:

    int *myPointer;
    myPointer = (int *) 0x4560;
    if (myPointer == (int *) &myPointer) return 1;

• EW11604
  Compiling the code below, using the intrinsic function read_ipl(), would crash the compiler without producing any error message. 

    if (read_ipl() > 0) {}

• EW11440
  Initialization of far data would go wrong if data straddles a 64k boundary. Linker files have been changed so that IDATA1 and CDATA1 start at the same offset from a 64k boundary.
• EW10797
  For medium and full write formatting, the near ROM segment CSTR is used and the function far_printf produces corrupt output. If you have no ROM in near memory you should use the clm16cy library even if you do not use writable strings for your own files.
• EW10065
  A semicolon was missing in the header file iom16c6n.h.
• M16CC0144
  Using the intrinsic function set_interrupt_table could generate an internal error (assemble_M31: Invalid syntax).
  Example:

    set_interrupt_table((unsigned long) RamIntTable);  

• M16CC0147
  The special function register IFSR was misspelled as ISFR in the file iom16c62.h.

1.35E, December 2001 (Not officially released)

• EW10996, M16CC0145
  When copying a struct the compiler sometimes, incorrectly, ignored that the generated SMOVF instruction modified the registers A0 and A1.

1.35D, October 2001 (Not officially released)

• M16CC0149
  Access to the volatile variable pause_counter was optimized away at optimization levels 8 and 9 for this example:

      void pause(unsigned char duration)
      {
        pause_counter = duration;
        while (pause_counter != 0);
      }
      

1.35C, July 2001 (Not officially released)

• M16CC0143
  When placing variables in a user-defined segment, the compiler would instead place them in the segment FAR_CONST if the attributes far and const were used. This has been temporarily corrected by allowing FAR_CONST to be disabled, using the NO_FAR_CONST environment variable. Observe that you must set this variable to circumvent the problem, and that it will disable the placing of far const objects in the FAR_CONST segment.

• M16CC0146
  When combining the attributes far and const in a typedef, an error was reported because the compiler tried to place the type (which is not an object) in the FAR_CONST segment. This has been temporarily corrected by allowing FAR_CONST to be disabled, using the NO_FAR_CONST environment variable. Observe that you must set this variable to circumvent the problem, and that it will disable the placing of far const objects in the FAR_CONST segment.

1.35B, July 2001 (Not officially released)

• M16CC0138
  Internal error occured in some cases of pointer arithmetic using far pointers and unsigned integers. The following did not work:

       far_pointer1 = far_pointer0 + uint_offset1;

• M16CC0139
  Multi dimensional arrays declared as far const were placed in the IDATA1 segment, instead of the FAR_CONST segment.
• M16CC0140
  Offset to parameters were incorrect for functions declared as monitor.

1.35A, January 2001

• M16CC0135
  Nesting structs and arrays using the far memory model would sometimes generate faulty code.
• M16CC0134
  The 'monitor' keyword stopped working when the frame pointer register was changed to FB.
• M16CC0133
  Function pointer assigments gave internal error in some cases, such as:

        typedef void (*tElement)(void *pParam);
        typedef struct tagTest
        {
           int      test;
           tElement Element[3];
        } tTest;
  
        void Test(tElement pElement)
        {
           tTest *pTest;
           int Index = 2;
  
           pTest->Element[Index] = pElement;
        }

• M16CP0131
  Optimization made incorrect assumptions, leading to volatile variables (sfrs) being modified twice in one assignment. For example the code 'P0 = i + 1' would load i into P0 and then increase P0:

      MOV.B  #1,3E0h
      ADD.B  R0L,3E0h
  

1.34A, January 2001

• M16CC0126
  The FB register was not saved on function entry, even though it was used for bit manipulations. The usage of FB and SB registers has changed, but whichever regiser used in this type of context will be saved.

• M16CP0127
  Updated the readme to indicate that the green dongles are no longer supported, due to the introduction of the new software copy-protection system.

• M16CC0128
  The compiler previously optimized the pattern:

        STZ #a,Rx
        MOV Rx,Ry

  into:

        STZ #a,Ry

  This is not correct, since the code snippets are not equivalent.

• M16CC0129
  The port direction registers where sfrp in "iccm16c62.h", this has been corrected to sfr for the non-paired direction registers.

1.33A, October 2000

• M16CC0124
  For optimization-levels z8/s8 and above the code:

      char c;
      long x <<= c;

  loaded the value of 'c' to register R1H and assumed the register was not changed after shifting. This is not true if the value of 'c' is greater than 15, so R1H is now considered garbage.

• M16CC0123
  The header-files in the real_hw directory had C++ comments in them, now they all use C-comments.
• M16CC0122
  Intrinsic set_interrupt_table generated internal error; this has been fixed.
• M16CC0121
  The port direction registers where 'sfr' in iccm16c62.h, this has been corrected to 'sfrp'.
• The library routines for long integer division has been improved considerably in speed.
• When optimizing for speed the shift library calls are inlined.
• Some enhancements were made to increase code speed (and size) by identifying patterns in the code.

1.32B, *unofficial*

• M16CC0120
  The initialization of a far pointer to an element of an array goes wrong, if the address was greater than the size of one element.

1.32A,

• Added an include file for M16C/62 (iom16c62.h).
• M16CC0114, G0078
  Copy propagation may go wrong if the propagated constant is an address. This has been fixed.
• M16CC0115, EBK0009
  Some labels had offset zero in the demo version of the compiler.
• M16CC0117
  Acessing an far array generated wrong code for code like the example below if the low byte of the start address minus a numerical constant resulted in a negative value.
  Example:

          /* Array linked to address 10000h */
          unsigned char Array[] = { 0, 1, 2};
          char PointerBug(int i) { return Array[i-2];}

• To make the code execute faster, cross call, cross jump, and interprocess cross jump, are no longer activated when optimize for speed is selected.
• Better code when accessing arrays located in the far memory area. Example:

      far const unsigned char char_lut[4] = {0xC0,0xF9,0xA4,0xB0};
      unsigned char char_display ;

  New code (with -z9):

      char_display = char_lut[value] ;
      7204 MOV.B R0L,A0
      7490...... LDE.B char_lut:20[A0],R0L
      03.... MOV.B R0L,char_display

  Old code:

      char_display = char_lut[value] ;
      75C1.... MOV.W #LWRD(char_lut),R1
      75C3.... MOV.W #HWRD(char_lut),R3
      7204 MOV.B R0L,A0
      A141 ADD.W A0,R1
      7314 MOV.W R1,A0
      7335 MOV.W R3,A1
      74A0 LDE.B [A1A0],R0L
      03.... MOV.B R0L,char_display

• New pragma, #pragma optimize. See "Manual corrections and updates".

1.31D, January 2000

• This is a version, for testing only.
• A new command line option (-E) is available. With this option enabled the compiler generates better code for one bit bitfields.
• M16CC0113
  if(1==2) {...}
if(1==3) {...}
  the compiler could not optimize away the code generated from the always false if statements. Now it can.

1.31C, October 1999

• This is a time-limited version.
  This product is only working for 30 days after installation. The last date for installation and execution of this product is 28 June 2000.

1.31B, September 1999

• M16CC0107
  An internal error (assign_colors_C01: coloring failed) could occur due to failed register allocation.
• The special libraries (m16c0.r34 and m16cd0.r34) to handle some hardware bugs in M30600 is provided with the product again.

1.31A, September 1999 [Not Released]

• M16CC0043
  Breakpoints could not be set in source code in include files when using IEEE-695 format in Renesas's PDB30 debugger.
• M16CC0089
  Two assignments to the same SFR ( like &=, |= ... ) resulted in an IE.
• M16CC0090
  If the last instruction within a function is a call to a function and as parameter a pointer to an auto variable is given, then the optimizer destroyed the stack before calling the function.
• M16CC0092
  An incorrect live/dead analysis resulted in faulty remove of the PUSHC,POPC.
• M16CC0094
  The ((unsigned char far *)(&bArray[2]))[1] = 12; was generating an IE.
• M16CC0095
  Multiple assignements to bits resulted in wrong code. i.e. P2.2= P3.1= P4.2= TRUE;
• M16CC0101
  Assignment of unsigned char bitfields in near memory model could (when mixing with assingment of other bitfields) sometimes generate wrong code. Example:

      struct {short a:4;} bits;
      struct {unsigned char a:4;unsigned char b:4} cbits;
      cbits.a = 5;
      bits.a = 7;
      cbits.b = 3;

• M16CC0102
  unsigned char huge * mem_ptr ;
CRCIN = *mem_ptr++ ;
  Resulted in wrong code when using the near memory model and -z4 and higher.
• M16CC0105
  STZX was incorrectly generated in an attempt to write to a bit variable.
• M16CC0106
  An IE occured for the code below.

  extern unsigned char Foo;
*((unsigned char far *)&Foo + tmpW0) = tmpB1 & (~tmpB2);

• M16CC0109
  The compiler generated wrong jump address in a huge switch.
• M16CC0108
  Wrong interrupt address in tutor3.c for timerA0.

1.30B, May 1999

• Only demo version.

1.30A, March 1999

• M16CC0051
  The full formatter for 'printf' and 'scanf' could not be used with the default settings in the near memory model since constant tables could not be accessed if they were stored outside the near memory area. New libraries are provided for this purpose. See section 2 above how to handle the situation when there is no ROM available in the default (near) area .
• M16CC0083
  The comments in the provided linker files were incomplete and sometimes gave incorrect information about the usage and limitations of the segments. This should be more clear now.
• M16CC0084
  Incorrect indexing for arrays with negative offset when using the 'far' or 'huge' memory model. The index value could be treated as unsigned and thus refer to incorrect memory elements.
• M16CC0085
  Externally defined relocatable bit variables were sometimes treated by the compiler as having an absolute location, thus generating incorrect code.
• M16CC0086
  On optimization level 7 (or higher) a conditional assign optimization could lead to incorrect code generation. The resulting STZ/STNZ instruction were not recognized as conditional assignments, thus making previous conditional assignments redundant and hence removed.
• M16CC0087
  The definitions of the intrinsinc functions 'rmpa_instruction' and 'short_rmpa_instruction' in INTRM16C.H were incorrect, as they could only be used in the near memory model. The RMPA instruction can only handle 'near' addresses (16-bit). When used in 'far' and 'huge' memory models, an internal error was generated.
• On high optimization levels (7 and above), an internal error could occur due to incorrect removal of redundant PUSH/POP instructions. Message: discard_paired_P54: should have found one Line/Nr/0
• The pre-defined system macro '__SIZE_T_TYPE__' was set to 'unsigned short' instead of 'unsigned long' in the huge memory model.
• It should now be possible to use the 'near' memory model, even if there is no ROM in the near area (up to address 0xFFFF). The '-y' switch (writable strings) has been extended to handle constants as well as dynamic allocation constants. See section 2 above about how to handle the situation when there is no ROM available in the default (near) area .
• The common sub-expression elimination optimizations are improved, most notably for the 'far' and 'huge' memory models. A typical example where the change can be seen is when an auto variable is frequently used as a data structure pointer.
• The special libraries (m16c0.r34 and m16cd0.r34) to handle some hardware bugs in M30600 is no longer provided with the product.

1.20C, November 1998

• M16CC0067
  On high optimization levels, consecutive PUSH/POP instructions were sometimes incorrectly optimized away, leading to an unsynchronized stack.
• M16CC0069
  Relocatable bit variables were sometimes treated as having an absolute location (solved at compile time) instead of relocatable (solved at link time).
• M16CC0070
  An internal error (assign_colors_C01: coloring failed) could occur in the far/huge memory model due to failed register allocation. Example:

  static near char array[3
static near index;
char *ptr;
*ptr=array[index]; /* internal error */

• M16CC0071
  Incorrect code was generated when using the -h option to generate code for the HP debugger. The SB register (used as frame pointer) was incorrectly initialized and was sometimes accessed with negative offsets.
• M16CC0075
  Division between a 'signed long' and a positive constant where the result was stored as a 'signed short' was executed as an unsigned division.
• M16CC0076
  An internal error (assign_colors_C01: coloring failed) could occur in the near memory model due to failed register allocation. Example: ('s' is a struct with several void pointer elements)

  s->arr[--s->arrp] = s->x; /* internal error */

• M16CC0078
  The DIV/DIVU instructions do not work as described in the software manuals from Renesas. When the division overflows, the result of the division is not transferred to the destination registers (only the overflow flag is set). Hence, the instructions DIV and DIVU cannot be used when dividing 'short=long/short' and 'char=short/char'.
  The corresponding optimizations are removed from the compiler.
• M16CC0079
  Incorrect use of bit variables for comparison could lead to an internal error (label_trees_C03, illegal state) due to an incomplete internal state description.
• In-line assembler is available in the compiler.
  Syntax: asm("any assembler statement");
  See section 2 for furter descriptions.

1.20B, August 1998

• M16CC0063
  When using word alignment on data (-u2, enabled default) and using preinitialized arrays with odd length as local variables, some auto variables or parameters could be overwritten.
• M16CC0065
  The compiler accepted SFR addresses up to 0xFFFFF without any warnings, even though only addresses below 0x400 are relevant. Now a warning ('Maybe an illegal SFR address') is raised if the SFR address exceeds 0x400.

1.20A, August 1998

• M16CC0004, G0038
  Cast between negative floating-point values and unsigned integers caused an internal error on optimization level 9. Now the warning "Floating point constant out of range" is given. The operation has no well-defined behavior in ANSI-C.
• M16CC0016
  A warning (unknown pragma) was given for code containing '#pragma alignment' if the -g (typ check information) switch was used. This was harmless but annoying and the generated code was correct.
• M16CC0032
  Inconsistent declaration of 'C_task' functions was not indicated with an error or warning as expected ('monitor' and 'interrupt' gave correct error messages).
• M16CC0041
  The include file IOM16C.H contained some erroneous or obsolete definitions. The definitions for SAR10 to DM1CON were on wrong addresses (starting at 0x020 instead of 0x030) and are now corrected. Some symbols in IOM16C.H have names that differ from the present user manuals. Two new files named IOM16C60.H AND IOM16C61.H are supplied and they use a more modern naming convention.
• M16CC0042, XLINK0052
  The linker sometimes generated an internal error, depending of the order of the linked files. Corrected with version 4.49X of XLINK.
• M16CC0044
  Internal error when using 'static bit' variables.
• M16CC0045
  On high optimization levels some AND/OR operations on absolute addresses were incorrectly optimized away. Several consecutive assignments were merged together although they referred to different memory locations.
• M16CC0048
  Fixed bit variables are not publicly available. This was not clearly mentioned in the documentation. See section 2 above.
• M16CC0049, M16CC0059
  Optimization of several consecutive AND instructions was done with incorrect immediate argument.
• M16CC0050, XLINK0066
  Incorrect warnings about type conflicts were given when linking. Corrected with version 4.50E of XLINK.
• M16CC0052, G0053
  A general protection fault was generated on the highest optimization level when doing a modulo operation (%) with a divisor containing a complex constant zero-value expression.
• M16CC0055, M16CC0056
  When reassigning a value to a 'far' pointer in the 'default/near' memory model, the storage location could be misplaced with two bytes. Also, the debug information (used by C-SPY) got rather confusing.
  Example: [declaration: unsigned long far *ptr, result stored at ptr+2]:

  *ptr = *ptr/10;

• M16CC0057
  Copying of a structure element within an array of structures failed due to invalid destination address for SMOVF instruction.
• M16CC0060
  Several consecutive operations on identical volatile operands were incorrectly optimized into one operation.
• M16CC0061
  Hardware patches mentioned in the section "important information", controlled with environment variable M30600_PATCHES, were not correctly activated on all optimization levels.
• M16CC0066
  When utilizing STZX to test and set the value of a 'near' variable in 'far' memory model at high optimization levels (8 or 9) and using HP debug mode (-h), the value was not always properly used to set status register flags. Following flag tests could give misleading results.
• The compiler front-end (and surrounding components) is changed to version 4.40. As a result there are some new command line options described above. The debug output now uses true UBROF6 file references. The previous versions did not fully utilize them.
• New optimizations added to enable the use of division instructions.

1.11B, March 1998

• M16CC0036
  Multiplication between unsigned long integers could sometimes lead to incorrect results due to defect register allocation. Example:

  Ulong1 = Ulong2 * (unsigned long) int3
  gave Ulong1 the value Ulong2*Ulong2

1.11A, February 1998

• M16CC0033
  The intrinsic inline call to library function strlen() generated incorrect code. The register holding the argument value could be re-used and hence destroy the variable value.
• The compiler now generates UBROF6 as default debug output format. See additional documentation above.
• The libraries are using version 3.33H of the C libraries. More detailed information is given in CLIB.TXT.
• Added optimizations for some patterns of AND/OR. This should reduce the code size for some bitfield operations.
• Optimized to avoid unnecessary PUSH/POP in empty functions.

1.10C, November 1997

• M16CC0012 again...
  Wrong source code for CSTARTUP.S34 was sent with version 1.10A. The compiled library object files were correct.
• M16CC0023
  The file IOM16C.H was not complete. Information about PM0 and PM1 is added. PM is changed from byte to word.
• M16CC0028, XLINK0026
  A problem in the type globalization routines in XLINK 4.49B could cause an exception (leading to an internal error) when reading input object files. Corrected in version 4.49G of XLINK.
• First official Windows version available.
• Incorrect constant propagation at the highest optimization level could cause an internal error.

1.10B, October 1997 (internal release)

• Improvements in the far model, with respect to memory utilization.

1.10A, September 1997

• M16CC0001, G0007
  A problem in the global optimization (highest level) caused a broken output file, which in turn caused an internal error in XLINK.
• M16CC0007
  A0 register data could be damaged on optimization levels 8 and 9.
• M16CC0008
  Intrinsic enable_interrupt was used incorrectly in file tutor3.c
• M16CC0009
  LDC instructions are no longer optimized away at optimization level 7 and above.
• M16CC0010
  Bit expressions (like p0.1 ^ 1) could cause an internal error.
• M16CC0011
  SHL.L was used with a too high parameter value in CLIB, leading to an undefined behaviour.
• M16CC0012
  Operator LOW was used instead of LWRD in the C-startup code in two places. This could cause incorrect initialization of writable strings (-y) and near data area.
• M16CC0013
  Intrinsic function `set_interrupt_table' now accepts relocatable and 16-bits arguments.
• M16CC0014
  Incrementing a far pointer stored in near memory no longer causes an internal error.
• M16CC0017, CG0002
  An internal error was generated when trying to cast a negative integer to an unsigned char, under certain circumstances.

  int a(void);
void rrm(void)
{
int i;
unsigned char VResult;
VResult = ( (i-1)) + a(); /* always ok */
VResult = ((int)(i-1)) + a(); /* gave IE:'bad EA text_Instr_P51' */
}

• M16CC0019
  Direct comparison between BIT variables (bitvar1==bitvar2) caused an internal error.
• Added memory models for far/huge pointers. Se section "important information" above.

1.01B, November 1996

• Added -h command line switch to support HP debugger.