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

Important information

• A new version of the DLIB runtime library is used in version 4.61A and onwards. This means that object modules produced with earlier versions of the compiler cannot be linked together with modules produced with the new version.

• Please refer to the IAR C/C++ Compilers Reference Guide for 78K for detailed information about this product part.

New features

• The code generated for some shift and rotate operations has been improved.

Known Problems

• The compiler does not check the MISRA-C:2004 rule 10.6 correctly. It bases the check on the usage of the constant instead of on the type of the constant. [EW24733]
• The intra crossjump optimization might crash in rare cases when optimizing a switch() statement. [EW24227]
• Casts to NULL might trigger error message Pe028 in cases where they should not. [EW22338]
• The CLIB version of sscanf is not as accurate as the DLIB version when handling char-to-float operations with values close to the maximum value that a 32-bit float can handle. [EW19268]
• The compiler discards any variable info for variables not referenced before the inline assembler is invoked, meaning that the inline assembler does not have symbolic information of a variable or function defined in C, if they are not used in a C-statement.
  Workaround:
  1. Use #pragma required
  #pragma required = var
  2. Use a dummy function that accesses the variables. It will be removed by the linker if it is never called. [EW16519]
• Using inline assembler with a function or variable that is not referenced from C earlier, causes the error message: Error[Og005]: Unknown symbol in inline assembly.
  Workaround:
  1. Use #pragma required = var
  2. Use a dummy function that accesses the variables. It will be removed by the linker if it is never called. [EW10146]
• The 78K preprocessor sometimes recognizes other symbols than pre-processor symbols, which is wrong. [EW20043]
• The compiler sometimes fails to recognize cases where the warning Pa084 "Pointless integer comparison" should be emitted. [EW21048]
• A tool internal error is generated when a macro is used to expand the usage of a code line. [EW22716]
• MISRA-C checker errors without a fileposition causes the compiler to crash when the option --header_context is used. [EW22668]
• Loops that contain two (or more) variables that are incremented with a constant amount each iteration but otherwise not used inside the loop body, can trigger a problem. One of the variables is used in the loop test and that variable is incremented before the other variable(s). [EW22623]

Program Corrections

• None

User guide corrections

• Section Calling convention, Function entrance
  The parameters are also passed on the stack in these cases:
  Structure types: struct, union, and classes, except structs of size 1, 2 and 4 with a minimum alignment of 2 if the size is 2 or 4. [EW24225]
• The _A_ prefix
  A member of an anonymous structure has the prefix _A_ when referred to from assembler code.
• A new runtime model attribute "__data_alignment" has been added to the 78K0R compiler
  Linking code compiled with --disable_data_alignment with the supplied 78K0R libraries could generate misaligned word accesses. It is no longer possible to link mismatching data alignment for 78K0R.
  If you want to build a project with data alignment disabled, you will also need to build the corresponding library because it is not supplied.
• Description of __segment_begin(segment) and __segment_end(segment)
  Page 195 in C78K-4 should be [EW23266]:
  #pragma segment="MYSEGMENT" __far
  ...
  segment_start_address = __segment_begin("MYSEGMENT");
• Type attributes
  Page 205 in C78K-4: If the declaration memory_attribute type *pointer; declares a variable, memory_attribute will determine in which memory the pointer is placed. Otherwise, if declaring a structure member, memory_attribute will determine the pointed-to memory. [EW22627]
• Section Data representation, Alignment
  For the 78K0R compiler, string literals and arrays always have an alignment of two, unless placed at an absolute address.
  Note: This will cause padding for odd-sized objects.

Miscellaneous

• Nothing.

Release history

2015-05-22 V4.80.3

Program corrections

• Using an unsigned variable as index type might generate illegal indexes if the variable type is smaller than the pointer index type. [EW25315]
• A certain combination of crossjump optimization and memory tracking might cause erroneous code generation on optimization level high. [EW24694]
• On high optimization, 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. [EW23994]
• An indirect postincrement of the result of a postincrement ( (*p++)++ ), is not handled correctly. [EW23972]
• Bit accesses on stack variables may access released stack memory on optimization level high speed or high balanced. This might cause errors if an interrupt occurs and destroys the released memory. [EW24895]

2014-04-23 V4.80.2

Program corrections

• Assigning a value from one 1-bit bitfield to another 1-bit bitfield might fail if the byte offset of the destination bitfield in the struct is not zero. [EW24645]
• Alignment of arrays is set to two by the 78K0R compiler even if they are placed at an absolute location. [EW24453]
• Bit access on pointers is sometimes performed even though the __no_bit_access keyword is used. [EW23938]
• Constant folding of far pointers might generate faulty addresses if the addition causes an overflow into bit 12 for the 78K0R compiler. This problem occurs when pointer arithmetics is done on a far pointer that has a constant integer value and another constant integer value is added to it and the result wraps over into bit 12. [EW23802]

2012-11-01 V4.80.1

Program corrections

• The compiler now generates a warning that the location is ignored for located near constants if the constants are copied to RAM. [EW23467]
• The compiler no longer generates incorrect code when it casts a near data pointer to a far pointer. This could result in the value 0 instead of 15 on low optimization levels. [EW23345]
• Using not on a one-bit bitfield of int type no longer generates incorrect code. [EW23311]
• Using memcpy with sizeof(segment) as a size parameter no longer causes an internal error. [EW23223]
• The compiler could in rare cases destroy the value of an index variable of a pointer if it was an unsigned char. This has been corrected. [EW23168]
• The stack usage calculation used the stack frame size of the calling function as the parameter size to a called function and hence reported more stack used than actually true. This has been corrected. [EW23126]
• Near pointer indexing no longer generates incorrect use of the word[BC] address mode if it is on the form array[-var]; or array[0x100-var];. [EW23052]
• A 32-bit variable placed at offset 254 in a struct no longer causes the compiler to generate an illegal instruction. [EW22973]
• Comparing two non-volatile char variables located in the saddr memory space no longer causes the 78K0R compiler to hang on high optimization levels. [EW22747]
• Using memcpy with a destination in the auto area no longer leads to incorrect code for 78K0R on high optimization levels. [EW22724]
• A bit-read that is cast to an int no longer causes an illegal exception. [EW22704], [EW22705]

2011-08-11 V4.71.2

Program corrections

• The compiler could generate an illegal address mode if an absolute placed variable was indexed with a negative value. [EW22605]
• Accessing far variables from within an interrupt routine could generate an internal error. [EW22570]

2011-07-04 V4.71.1

Program corrections

• When casting an address of a short address variable to a far pointer, the compiler no longer optimizes the code in a way so that an internal error is generated. [EW22465]
• A variable stored on top of the stack and the value stored is a return value from a function with a ... parameter is no longer storeed to the wrong location. [EW22430]
• Casting an SFR address to a far pointer no longer results in the far pointer pointing to the wrong memory page. [22286]
• The compiler no longer generates an internal error for constructions like:
  #define u16GetIF0 (*((volatile unsigned short int __far *) (0xffe0u)))
  ...
  if (u16GetIF0 != 0x5678u)
  ...
  [EW22160]
• Calling strcpy or memcpy in the far data model for 78K0R no longer causes an internal error. [EW22112]
• A bit test-and-branch instruction that jumped to the very next instruction no longer causes the compiler to generate an internal error. This only occured for optimization level low or none. [EW22069]
• The intrinsics functions __segment_begin(), __segment_end(), and __segment_size() can now be used as argument in a function call when optimizing. [EW22023]
• The compiler no longer generates an internal error for code that contains a BTCLR instruction. [EW21953]
• switch variable values larger than 0xFFFF now execute the default case as expected. [EW21951]

2010-06-20 V4.70.1

New features

• Improved optimization
  The compiler has been optimized both for smaller code size and higher execution speed, compared to the previous version.

• New pragma to control loop unrolling
  #pragma unroll lets the user control both if a loop will be unrolled and the aggressiveness of the transformation. The pragma directive will override the normal unrolling heuristics so it will be possible to unroll loops that normally would not have been considered candidates for loop unrolling.

• Force far function calls option introduced
  A compiler option, --generate_far_runtime_library_calls, has been added to make it possible to place libraries (the RCODE segment) in far code memory.

Program corrections

• Code could be scheduled past __no_operation() calls for 78K0R even though this is not allowed. [EW21730]
• An if test that could result in a bit test instruction could fail if it was immediately followed by a "clear" of the variable tested in both branches. [EW21727]
• Casts from long to a far function pointer caused an internal error. [EW21677]
• On optimization level high-balanced or high-speed for 78K0R, a call to strcmp with one parameter could generate code that accessed words at an uneven address. [EW21556]
• Due to missing statement information in the debug information generated by the compiler, breakpoints could in rare cases not be set on specific C source lines. [EW21796]
• An optimization trying to determine whether a test had the same outcome for all values of the loop variable didn't handle expressions over- or under-flowing (going from UINT_MAX to zero, or vice versa) correctly. [EW24492]

2010-03-02 V4.62.5

• The realloc function in CLIB could fail if the size was very large. [EW21631]
• The jmpbuf was byte-aligned which could cause memory next to it to be overwritten if the jmpbuf was placed at an odd address. This has been corrected. [EW21625]
• On optimization level high or high-speed for 78K0R, a call to strcmp with one parameter could generate code that accessed words at an uneven addresses for string literals. [EW21556]
• A construct like (const t_examns []){e_math1 , e_phys1 , e_phys2 }; where e_xxx are enums, was not placed in ROM but in RAM. [EW21431]

2009-11-13 V4.62.3

• Packed structs could cause misaligned access error. This has been corrected. [EW21422]

2009-07-01 V4.62.1

• The compiler now generates a remark when a hexadecimal or octal constant is implicitly cast in a way that it changes the sign of the constant. [EW21004]
• Some code parts could be scheduled past a DI instruction for 78K0R. This has been corrected. [EW21002]
• Initializing a global __far pointer with the address of a __near object in the ROM0/ROM1 area no longer causes the far pointer to point into the ROM0/ROM1 area instead of the ROM-window in the __near area. [EW20770]
• Functions containing a so called diamond construction that uses different amounts of stack and is immediately followed by a while(1); construction no longer generates an internal error. [EW20744]
• Comparing an external union element with an immediate value does no longer cause an error when the medium or lower optimization level is used and the union is located in __saddr memory. [EW20740]
• Structs that contained only char elements could be accessed using a MOVW instruction, causing an alignment error. [EW20722]
• 78K0R now initializes the stack to avoid accessing uninitialized RAM. This could occur when a returning function cleaned the stack of pushed parameters. [EW20669]
• Misaligned word-accesses could occur in 78K0R even if --disable_data_alignment was on. This typically occured for assignment operations on short variables. [EW21050]

2008-12-15 V4.61A

• The floating-point routines used for 78K0R and DLIB were not interrupt-safe if an interrupt routine updated a variable located in the short address area 0xFFE20-0xFFE27. This has been corrected. [EW20661]
• Long compares with an immediate could generate faulty code for 78K0/78K0S. [EW20553], [EW20432]
• For 78K0/78K0S, banked function calls could fail on high optimization levels if several calls were made within the same function and the passing of parameters and return values in registers differed between the calls. [EW20475]
• The MISRA-C:2004 rule 10.6 ("use the 'U' suffix") could sometimes trigger for enum constants. [EW20443]
• The MISRA-C:2004 rule 17.4 would incorrectly trigger for arrays embedded in structures. [EW20395]
• Using float and long operations in 78K0R could fail with a read from un-initialized RAM. This has been corrected. [EW20302]
• The compiler could erroneously emit warning Pa084, "Pointless integer comparison", in cases involving the greater than or equal (>=) operator. [EW20559]

2008-07-02 V4.60A

• Using the compiler option -s9 in combination with --workseg_area can no longer cause the compiler to hang. [EW19810]
• Using ~ on a char bitfield that was cast to an int no longer causes an internal error for 78K0/78K0S. [EW19662]
• The compiler no longer generates an incorrect assembler instruction for 78K0/78K0S, that cannot distinguish between two symbol names that are identical apart from upper-/lower-case. [EW19636]
• The compiler no longer reports an incorrect size on DBNZ for 78K0/78K0S causing an internal error if scr was a saddr type. [EW19632]
• An optimization peephole rule that generated an internal error for certain code constructions has been corrected. [EW19547], [EW19186]
• Casts between function and data pointers of the same size no longer causes an internal error for 78K0R. [EW19515]
• Mixing unsigned and signed bitfields in the same struct no longer causes a crash for 78K0R. [EW19514]
• Assigning a float variable to a signed int bitfield no longer causes the compiler to fail with an internal error for 78K0R. [EW19513]
• Long arithmetic and logical operations no longer corrupt the stack for 78K0R. [EW19512]
• Speed optimizing C switches could result in an internal error for 78K0R. [EW19511]
• For 78K0R, C switches with test cases that take care of every possible option no longer generate incorrect code if all cases use the same code. [EW19510]
• A problem with the 78K0R compiler that sometimes generated an internal error for pointer arithmetics has been corrected. [EW19509]
• Deeply nested loops could cause incorrect code to be generated for 78K0R. [EW19343]
• Tests where an expression containing a left shift is compared to a constant are now optimized correctly for 78K0R. [EW19307]
• If the auto area of a function is an even multiple of 256, the 78K0R compiler now works correctly. [EW19279]
• Accessing multi-dimensional arrays now generates correct code for 78K0R. [EW19278]
• A loop that contains multiple integer expressions on the form constant_scale_factor * i + constant_offset and sizeof(constant_offset) and differed between the expressions, is now optimized correctly. [EW19271]
• For 78K0R, casts from float to long no longer differ if the 'from' value is a constant or a variable. [EW19267]
• The strrchr() function now returns the correct result when the second parameter is '\0'. [EW19266]
• C case statements that should not be executed, were sometimes executed for 78K0R. [EW19265]
• In some rare cases the optimizer failed to take into account that a function call could change the contents of a memory cell that a pointer variable (p) pointed to and assumed that *p had the same value as before the call. [EW19262]
• The 78K0R compiler could rewrite code to bit operations that used bit offsets outside the size of the integral type. This has been corrected. [EW19261]
• Negating a long variable no longer generates a 'coloring failed' error. [EW19212]
• Partial assignments to a variable where the address of the variable was cast to another pointer type should no longer cause an internal error. [EW18959]
• Using a for loop with a locally declared static variable could crash the compiler. [EW18872]
• The warning Pe177 could be issued even if the keyword __root was used, which implied that a variable might not be used in the module. [EW18508]
• The MISRA C diagnostics that should be issued when compiling with IAR extensions turned on, will now be issued. [EW18086]
• The following Internal error should no longer appear when using the command line option --mfc:
  Internal error: [CoreUtil/General]: OgModuleLabels -- label already defined
  [EW18571] , [EW18048]
• Instantiating a template class like vector on a function type no longer results in an internal error after several error messages. [EW19668]
• The following code generated an internal error: [EW19964]
  #define interrupt __interrupt
  #define __interrupt interrupt
  __interrupt void foo(void){}
• The 78K0/78K0S compiler could hoist a MOV A,PSW past a DI instruction. [EW20059]
• Function pointers as numeric constants no longer cause an internal error for 78K0R. [EW20067]
• The compiler could in some cases emit incorrect debug information for typedef types. When linking with XLINK, this could result in spurious type conflict warnings. [EW19822]

2007-10-09 V4.50C

• Using the __non_banked keyword together with the pragma directive forward_attribute caused an internal error. [EW19215]
• A memory aliasing problem could occur in far data model on high optimization levels. [EW19259]
• Accessing the last member of a struct with 128 short member via a pointer could result in a corrupt pointer. [EW19260]
• Assigning a value to a bit in a bitfield, part of an array of structs, could go wrong. [EW19272]
• Taking the address of an object in an array and passing it as the first parameter to a function could sometimes generate faulty code. [EW19263], [EW19264]
• Code that resulted in a MOV A, [HL+B/C] instruction could destroy the B/C register before accessing the memory. [EW19312]
• The SEL RB instruction could be optimized away on higher optimization levels if the interrupt function was big enough to use all 4 register pairs. [EW19342]
• Character division could generate faulty code under some circumstances. [EW19546]
• In some rare cases, a series of assignments could be incorrectly optimized away. Example: [EW19495]
  x = ...;
  y = x;
  x = !z;
  ...
  use(y);

2007-07-06 V4.50B

• Casts from __near to __far_func caused an illegal state internal error, and casts between __far and __far_func caused an internal error "casts to same size". [EW19206]
• Using #pragma pack with 78K0R on __far objects in the near data model could generate faulty access code. [EW19177]
• Placing variables in a reserved segment could cause an internal error. [EW19166]
• Pointer/array expressions that resulted in a bit test instruction caused an internal error for 78K0S. [EW19137]
• An unhandled exception could occur on medium and high optimization levels. [EW19083]

2007-05-11 V4.50A

• Post increment/decrement on absolute variables caused an internal error for the 78K0R compiler. [EW18462]
• For certain code, the linker generated a range error message for near constants if the compiler option -z3 was used with the 78K0R compiler. [EW18557]
• Adding a variable to an array placed in SFR memory could result in wrong code for 78K0. [EW18807]
• For low optimization levels, comparing two 1-bit bitfields could generate faulty code. [EW18863]
• The CS and ES registers were not saved in interrupt routines for 78K0R. [EW18873]

2006-10-05 V4.40B

• Using #pragma location to set segments to static banked functions could cause the compiler to generate wrong code. [EW18290]
• Range checks caused a linker error for constants located in the mirror 0 and mirror 1 area. [EW18390]
• Bit tests against the short address area could generate faulty code for 78K0R. [EW18450]
• A 16-bit access to an SFR outside the short address area could generate an illegal instruction. [EW18455]
• Tests directly against the return value of a function could be optimized away in rare circumstances. [EW18241]
• Complex logical operations resulted in an illegal state if the right operand was a complex expression resulting in a carry operand. [EW18249]
• Bit tests in an if statement could cause an internal error. [EW18306]
• The label for interrupt vectors were of the wrong kind and could generate link errors if MISRA C was enabled. [EW18449]

2006-07-07 V4.40A

• Including an I/O definition header and referencing more than one SFR from C++ code will no longer result in incorrect warnings when linking. [EW17929]
• The library function vswitch for integers only supported up to 127 cases. [EW17863]
• Interrupt functions that had an auto area size that was odd could potentially destroy registers in other register banks at exit. [EW17787]
• A construction of type:
  char var;
  if ( var-- )
  { ... }
  where var was located in workseg, could generate faulty code. [EW17706]
• At optimization level high, incorrect code could be generated if a loop had an unsigned loop counter, the loop counter was decremented, and the loop contained a test (besides the loop exit test) where the loop counter was compared to an immediate. [EW17705]
• Some violations of MISRA C rule 83 (implicit conversion of return value) were only detected if rule 77 (implicit conversion of function parameter) was also turned on. [EW17277]
• A reference to a static symbol with file scope from an inline assembler statement no longer generates an error. [EW17193]

2005-09-05 V4.30C (patch release)

• Between version 4.20A and 4.30A a bug related to interrupt vectors were fixed. This caused an incompatibility between object files created with different versions of the compiler. Now, a linker error is generated if you try to link an object file produced with an earlier compiler version with a file produced with version 4.30C. This also means that libraries have to be rebuilt to be compatible with the new version of the compiler. [EW17188]
• The option --disable_data_alignment could cause illegal byte accesses to word SFR's. [EW17169]
• Using the __banked keyword or the banked code model, it was possible to place interrupt functions in banked memory. [EW17082]
• Using tiny calls could cause the compiler to make false assumptions about memory contents which lead to too aggressive optimization. [EW17014]
• Alignment of linked variables could cause unnecessary holes in memory. [EW17069]
• The compiler generated a non-banked call if a non-banked function called a static banked function. [EW17240]

2005-07-15 V4.30A

• The compiler generated wrong code for assignment of a bitfield element using logical operators. Example:
  Bits1.bit0 = ~FBits0.bit7; [EW17029]
• Assigning a 1-bit bitfield to another 1-bit bitfield, where the destination address must be calculated at runtime, could generate faulty code. [EW16862]
• The compiler could erroneously hoist (move) code past a register bank select instruction. [EW16846]
• Writing to a 1-bit bitfield could fail if the compiler had to use the [HL] address mode. [EW16813]
• For high optimization levels, the compiler sometimes used wrong access order for a sequence of multiple accesses to the same bitfield. [EW16739]
• Comparisons on a volatile char could be optimized away if the variable was set immediately before the comparison. [EW16683]
• Constructions like a[i] = i; where i was a register variable could cause the compiler to generate in-correct code. [EW16554]
• The call chain information got corrupted if both non-banked and banked functions were mixed. [EW16403]
• A re-definition of a symbol using __no_init, now generates an error. [EW16202]
• The compiler now emitts a warning if a reserved segment name is used as location for variables and functions. [EW16143]
• Using the --diagnostic_tables option caused an internal error. [EW16130]
• The compiler now generates re-locatable instead of absolute entries for interrupt vectors. [EW16067]
  Note: If user has overridden the CSTARTUP.S26 then the INTVEC segment definition must be changed from absolute to relative.
• The optimizer emitted the following internal error for a specific piece of code:
  [CoreUtil/General]: Const_Folding - Internal error. [EW16876]
• Blocks that ended in bit stores and were merged by the optimizer could generate wrong code if the bits where located in the same byte. [EW16870]

2004-10-26 V4.20A

• Located structs declared const caused an internal error. [EW15885] 
• It is now possible to change or delete the default compiler include path. [EW15717]   
• Certain code constructs could generate an internal error if high speed optimization was selected. [EW15607] 
• A volatile declared load of a short variable on an absolute address could be optimized away. [EW15585], [EW15587]   
• The __callf keyword was in-correctly enabled for the 78K0S core option. [EW15549] 

2004-05-14 V4.11A

• First release of V4.xx