- Important information
- New features
- Known problems
- Program corrections
- User guide corrections
- Miscellaneous
- Release history
Important information
- Binary compatibility
A consequence of moving to the new ISO/IEC 9899:1999 compliant compiler platform is that object modules produced with earlier versions of the compiler cannot be linked together with modules produced with version 4.10 and onwards. - Read the V850 IAR C/C++ Compiler Reference Guide for detailed information about this product component.
New features
- None
Known Problems
[EW25714] In some cases where statements are optimized away, the DWARF debug info will not be 100% correct.
[EW18014] When using dynamically allocated memory, either direct or indirect, one library variable will be placed in the HUGE_Z memory segment. Make sure that this segment is mapped to physical RAM memory. See the linker command file and the map file for information about placement of the HUGE_Z segment.
[LB331] Inline assembler cannot access variables with an absolute location. This includes all SFR registers. Workaround: By accessing the SFR from C in that compilation unit (that is the same source file), the variable will be visible to the inline assembler.
Program Corrections
-
[EWV850-455] On optimization level Medium and higher, the compiler tries to optimize instructions that load a register with an immediate value by finding another register that already contains that value. This generates incorrect code if the lowest 8 bits have the same value.
-
[EWV850-457] 32-bit switch cases that end up using value tables can fail, if the difference between two cases that follow on each other is larger than a signed 16-bit value.
User guide corrections
- #pragma default_function_attributes
Syntax: #pragma default_function_attributes=[attribute...]
where attribute can be:
type_attribute
object_attribute
@ segment_name
Description: Use this pragma directive to set default segment placement and type and object attributes for function declarations and definitions. The default settings are only used for declarations and definitions that do not specify type or object attributes or location in some other way. Specifying a default_function_attributes pragma directive with no attributes, restores the initial state where no such defaults have been applied to function declarations and definitions.
Example:
#pragma default_function_attributes = @ "MYSEG"
/* Functions that are placed in segment MYSEG */
#pragma default_function_attributes =
- #pragma default_variable_attributes
Syntax: #pragma default_variable_attributes=[attribute...]
where attribute can be:
type_attribute
object_attribute
@ segment_name
Description: Use this pragma directive to set default segment placement and type and object attributes for declarations and definitions of variables with static storage duration. The default settings are only used for declarations and definitions that do not specify type or object attributes or location in some other way. Specifying a default_variable_attributes pragma with no attributes restores the initial state of no such defaults being applied to variables with static storage duration.
Example:
#pragma default_variable_attributes = @ "MYSEG"
/* Variables that are placed in segment MYSEG */
#pragma default_variable_attributes =
- --enable_restrict
This command line option enables the Standard C keyword restrict. This option can be useful for improving analysis precision during optimization.
- --enum_is_int
Use this command line option to force the size of all enumeration types to be at least 4 bytes. Note: This option will not consider the fact that an enum type can be larger than an integer type. To set this option from the IDE, use Project>Options>C/C++ Compiler>Extra Options.
- The data_alignment pragma directive
It shall be noted that this pragma directive only gives the immediately following variable a higher (more strict) alignment of the start address than it would otherwise have. [EWV850-450]
- Description of predefined preprocessor symbols [EWV850-444]
- __TID__
A symbol that expands to the target identifier which contains these parts:
- t, a target identifier, which is unique for each IAR compiler. For the V850 controller, the target identifier is 85.
- c, the value of the --cpu or -v option
- m, the value reflects the setting of the --data_model option; the value is defined to 1 for Tiny, 2 for Small, 3 for Large and 4 for Medium.
- s, with (1) or without saddr (0).
The __TID__ value is constructed as: (0x8000 | (t << 8) | (c << 4) | (m << 1) | s)
You can extract the values as follows:
t = (__TID__ >> 8) & 0x7F; /* target id */
c = (__TID__ >> 4) & 0x0F; /* cpu core */
m = (__TID__ >> 1) & 0x07; /* data model */
s = __TID__ & 0x01; /* saddr support */
Note: The use of __TID__ is not recommended. We recommend that you use the symbols __ICCV850__, __CORE__, __DATA_MODEL__ and __SADDR_ACTIVE__ instead.
- __COUNTER__
A macro that expands to a new integer each time it is expanded, starting at zero (0) and counting up.
- __MEMORY_MODEL__
An alias to __DATA_MODEL__
- __TID__
Miscellaneous
- Migration information can be found in the V850 IAR Embedded Workbench Migration Guide.
Release history
2018-12-11 V5.10.1
Program corrections
-
[EWV850-446, TPB-2659, EW25971] Using IAR function object attributes (like __monitor) with member functions of template classes defined outside the class definition does not work properly. Specifying the attribute both on the declaration and the definition of the function results in a nonsensical error message ("declaration is incompatible with ..."). This is not a code generation error.
New features
- New command line option --enum_is_int
This option is used to force the size of all enumeration types to be at least 4 bytes.
2015-10-22 V4.20.1
Program corrections
[EW24733] 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.
New features
- The add-on product C-STAT for static analysis is now supported.
- A new command line option --version, that outputs version information, has been added.
2014-06-26 V4.10.3
Program corrections
[EW24056] Using __saddr in a variable declaration with an initializer causes a tool internal error.
[EW23965] 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.
[EW23972] An indirect postincrement of the result of a postincrement ( (*p++)++ ), is not handled correctly.
New features
- Two new pragmas, #pragma default_function_attributes and #pragma default_variable_attributes, are introduced to set default segment placement and type and object attributes for variables and functions. See section User guide corrections for more information.
2013-07-12 V4.10.2
Program corrections
[EW24051] Using the extended keyword __saddr caused a tool internal error.
2013-05-30 V4.10.1
Program corrections
[EW23576] For optimization levels balanced or high favoring speed, index calculation sometimes goes wrong for a loop where the loop count is known.
[EW23492] The cross-call optimization fails to generate padding NOP instructions in rare cases.
[EW23405] Using large signed constants with the medium data model and optimization level high sometimes generates an internal error.
[EW23250] The compiler can hoist a __set_interrupt_state function call past a conditional branch which in turn might cause the wrong branch to be taken.
[EW23174] A loop with an unknown loop count that initializes an array with a constant value might generate faulty code on optimization level high
New features
- C99 compliance
The IAR C/C++ Compiler for V850 now supports the ISO/IEC 9899:1999 standard. - Call Graph window
A new Call Graph window has been added. It is browsable and displays all calls made to and from each function from any source file in the active project. - Improved optimizations
Code generated for floating-point operations is now faster compared to the previous version.
2012-03-15 V3.81.1
Program corrections
[EW22887] The boolean result of comparing a long long variable with a constant was not correct.
[EW22576] __brel declared variables could be treated as const if they were used together with #pragma location.
[EW22489] Loading of an address to an sfr could in rare cases result in an internal error.
[EW22478] Qmark expressions with 64 bit long long values could result in an illegal state error.
[EW22432] Copying from a constant struct with zero contents could destroy a pointer register.
[EW22327] while loops with test on __get_processor_register() no longer fails at high optimization levels.
New features
- V850E2S support
Support for the new V850E2S Microcontroller family has been added.
2011-03-31 V3.80.1
Program corrections
[EW21499] In some cases two tests on the form expr1 > c1 && expr2
c2 [EW22100] Nested loops with loop variables of different types could in some very rare cases trigger an internal error.
[EW21825] An internal error was generated for code sequences trying to determine the greatest of two values where one of the values was placed in memory and the compiler tried to use the MAXF instruction. This only happened when the --fpu option was set to single or double.
New features
- Improved optimization
The compiler has been optimized both for smaller code size and higher execution speed, compared to the previous version. Also, calling functions for the V850E2 core is now more efficient.
2010-03-05 V3.71.2
Program corrections
[EW21627] The compiler now accepts placing located variables on addresses that are not properly aligned (on the V850E and above) as some devices have such peripheral units.
[EW21626] The compiler failed to generate correct code when the constant -32768 was used in some comparison expressions.
[EW21623] Incorrect code was generated in some cases when an access was performed via a pointer and the offset was larger than +-32KB.
[EW21620] When using the option --enable_multibytes, the compiler could crash when using a constant string that contained tabs.
[EW21445] When creating a constant pointer to a constant anonymous array, the anonymous array is located in RAM and not in ROM as expected for a const declared element.
2010-02-01 V3.71.1
Program corrections
[EW21430] When SFR registers were read in blocks, 16-bit SFR registers were read as 2 bytes instead of a halfword.
[EW21005] The compiler now generates a remark when a hexadecimal or octal constant is implicitly casted in a way that it changes the sign of the constant.
2009-10-28 V3.70A
2009-08-04 V3.61A (update)
Program corrections
[EW21049] Using _mul64 in a large program could result in an illegal register allocation.
2009-04-20 V3.60A
Program corrections
[EW20618] The and operation was not performed when masking a value that should be right-shifted and the number of zeroes to the right in the mask value was higher than the number of shift-steps.
[EW20559] The compiler could erroneously emit warning Pa084, "pointless integer comparison", in cases involving the greater than or equal (>=) operator.
[EW20468] When compiling with high speed optimization, the compiler could in rare cases generate the error "The instruction at 'xxxxxx' referenced memory at '0x00000'. The memory could not be read".
[EW20451] When a constant was used to define the size of an array and the pre-processor #define for that constant was missing, the compiler crashed.
[EW20421] The Misra C 2004 rule 17.4 would incorrectly trigger for arrays embedded in structures.
[EW20402] In some cases, a switch node could trigger the internal error "not a label-branch".
[EW20270] A source file with a loop with a trivial body could, in rare conditions, trigger an "illegal state" internal error.
[EW20257] Complex address expressions with multiple casts could in some cases cause an internal error.
[EW20250] The compiler generated a faulty warning for declarations like: __root const int toto@0x10000= 0x12345678;
[EW20912] In some rare cases, different code could be generated depending only on how long the C source file folder path was.
2008-06-20 V3.50A
Program corrections
[EW18086] The MISRA C diagnostics that should have been issued when compiling with IAR extensions turned on, is erroneously suppressed.
[EW18270] The cross-call optimization used branch instructions for routines located further away from the call than the allowed 8-bit offset. This caused a linker error.
[EW18872] The following example code generated a fatal error in the previous release:
for( static int i = 0; , i++);[EW18959] The following example code generated an internal error:
if(Test_Variable > 255) {
*((unsigned char*)&Test_Variable) = 255;
}[EW19499] An internal error was generated when adding an offset to an address to a function.
[EW19668] Instantiating a template class like vector on a function type no longer results in an internal error after several error messages.
[EW19186] An optimization peephole rule that generated an internal error for certain code constructions has been corrected.
[EW20053] A problem in the optimizer that generated the internal error "Internal Error:[any]: unexpected exception", has been corrected.
[EW20075] Expressions involving multiple shifts of a signed value could in some cases be optimized incorrectly. This has been corrected.
[EW20083] A problem in the optimizer that could lead to generation of the internal error "Internal Error: [any]: unexpected exception", has been corrected.
[EW20086] A problem in the optimizer that could lead to generation of the internal error "Internal error:[CoreUtil/General]: not a label branch", has been corrected.
[EW20090] Variables with the volatile attribute could sometimes be treated as non-volatile.
2007-07-25 V3.40B
Program corrections
[EW19256] Volatile data access was in certain cases not handled correctly when optimizing for speed, level medium or high.
[EW19311] When using optimization level high, NOP intructions could be optimized away.
[EW19251] When optimizing by locking registers under Project->Options->C/C++ compiler->Optimizations, cstartup initialized R18 and R19 with the value 0xff and 0xffff despite the fact that the option Put constants 255 and 65535 into registers was not set.
2007-06-13 V3.40A
Program corrections
[EW18250] Certain source code leading to mis-aligned memory access was allowed by the compiler. This is now illegal and results in an error message.
[EW18270] The cross-call optimization used branch instructions for routines located further away from the call than the allowed 8-bit offset. This caused a linker error.
2006-06-02 V3.30B (patch)
Program corrections
[EW18112] The compiler generated spurious errors for unevaluated parts of constant expressions in some circumstances.
Example: const unsigned int z1d = ( (0) ? ( ( 1 >= (1ul << -6) ) ? 1 : 2 ): 1 );
This expression contains a negative shift count, which would normally result in a diagnostic, but the problem is in the non-evaluated part of the conditional expression, so this diagnostic is suppressed. The negative shift count makes the comparison undeterminate, which resulted in a "constant value is not known" diagnostic. This subsequent diagnostics was not suppressed, which it also should have been.
2006-05-12 V3.30A
Program corrections
[EW16640] In rare cases, the Loop unrolling optimization lead to internal error when compiling.
[EW17646] Due to a memory dependancy problem in the instruction scheduler, generated code could slightly differ between two subsequent builds.
[EW17875] When more than two interrupt service routines contained an infinite loop, an internal error could be generated when using the highest optimization level.
[EW17555] Occasionally, the compiler could generate the internal error "Mismatch in cross call count" if high size optimization was used.
[EW16856] Debug information could be erroneous for optimization level 9 and code with lots of functions with common exit sequences.
2005-06-20 V3.20A
Program corrections
[EW16740] For high optimization levels, the compiler sometimes used wrong access order for a sequence of multiple accesses to the same bitfield.
[EW16382] Under some circumstances, having inline assembler code in a destructor function, or in an inline member function called from a destructor function, could result in an internal error when compiling.
[EW15800] A function that includes calls to variable argument functions and does not return, for example ending with a while(1) loop, could cause an internal error.
[EW16802] Restoring EIPC when returning from an interrupt function failed if compiled with no optimization.
[EW16809] The optimizer loop idiom recognition could cause an internal error for certain code sequences.
[EW16877] The instruction scheduler could hoist (move) instructions past NOP instructions.
[EW16937] A problem has been corrected where two interrupt vectors defined in different modules but with the same address, were not flagged by the linker as an error.
2004-10-20 V3.10A
Program corrections
[EW15300] In some cases variables used for indexing inside a loop body could have incorrect values after the loop. The problem could occur if the loop:
* found the max/min element in a vector,
* computed the sum of a vector,
* set all elements in a vector to a constant value, or
* copied elements from one vector to another.[EW15302] The compiler could on high optimizations generate addresses with a negative offset. This could cause the linker to generate an error if the symbol with the offset was located at the start of the near segment.
[EW15342] If a loop contained two or more assignments to elements in the same array, where at least one index was zero and at least one index was non-constant, and all elements were assigned a loop invariant value, the assignment to element zero could be hoisted out of the loop.
2004-03-25 V2.31A
2004-01-22 V2.30A
Program corrections
[EW14643] The right hand side of a compound assignment (+=, *=, etc.), or a simple assignment that could be transformed to a compound assignment, could in some rare cases be incorrectly eliminated as a common subexpression.
[EW14171] When compiling a new/delete expression in EC++ code at optimizations of Medium or High, if the code for the constructor/destructor was not visible, the compiler sometimes referred to the special 'new constructor'/'delete destructor' by an incorrect name, resulting in undefined external errors when linking.
[EW14089] Some load instructions in the library routine "FAR_V_Sw" (L06) where 16 instead of 32-bit.
[EW13855] Using the array delete operator (delete []) with an element type that has a constructor but no destructor caused an internal error when compiling.
2003-01-08 V2.21A
Program corrections
[EW12069] In some cases an expression could be hoisted out of the loop during loop optimization, even though it contained a variable defined in the loop.
[EW12071] Nested loops using the same loop variable could be optimized incorrectly if the increment or decrement of the loop variable preceded the inner loop.
[EW12155] Partial object assignments were interpreted as an assignment of the whole object. This could cause incorrect elimination of assignments.
[EW12156] Sometimes loops that were unrolled to straight line code could be optimzed incorrectly.
[EW12157] When 'for' or 'while' loops were fully unrolled, side effects in the test would not be executed for the final iteration.
[EW12172] When pushing a non scalar function argument on the stack, the LR register was sometimes erroneously destroyed. [EW12158], [EW12159],
[EW12177] In some cases a loop where an array element was subtracted from another array element, could cause the compiler to crash.
[EW12228] When compiling EC++ code with space-optimization medium or higher, the compiler generates a special routine for calling operator 'new' and the constructor and uses this when a new expression is compiled. If any of the parameters to the constructor were objects passed by value and needing a constructor call, this routine, and the calls to it, were generated incorrectly.
[EW12321] The code generated by the compiler could change depending on the compiler execution environment. The generated code was correct but the size could differ. This could be caused by moving to a different Windows OS, changing the environment settings, length of file paths or other changes that could change the memory allocation order within the compiler process.
[EW12389] Due to an optimizer error, wrong value was checked for an expression like: if (p->flags & 4).
[EW12556] The zero-extend-halfword-flag was incorrectly propagated as a zero-extend-byte when transferring information for a MOV instruction.
[EW12677] When a right shift and a left shift were combined into a single shift and a mask operation, the mask value was always calculated as if the shifts were unsigned.
2002-01-15 V2.20A
Program corrections
[V850C0023] LA0 (Base address of table) and LA1 (Normalized value to search for) were switched in the library file. [EW10028],
[V850C0026] If the highest optimization was used, a sort algorithm went wrong.[EW10033],
[EW10034] Problem with address of, and aliases.
[V850C0022] Problem when passing a variable of structure type (struct, class etc.) as a parameter to another function. [EW10035],
[V850C0024] An Internal Error was generated at the highest optimization level. It was caused by the loop optimization part of the global optimizer. [EW10036],
- An Internal Error was generated that was related to GO bug 373.[EW10039]
[EW10282] An Internal Error was generated when zero was compared to a bitfield, negated.
[EW10649] Only a return instruction was generated for a certain piece of source code.
[EW10507] In some cases the compiler generated wrong code at the highest optimization levels. The live/dead analyzer erroneously considered a CMP instruction as dead in an if-statement and hence removed it.
[EW10518] Problem caused by the global optimizer that had to do with loop invariant optimizations.
[EW10672] The compiler generated unsigned long even for smaller 'enum' types.
[EW10978],[EW12178] Expressions like a > b + 1 were rewritten as a >= b, but that changed the behavior when the expression b + 1 would have overflowed. The ANSI standard allows the transformation, since the behavior at overflow is unspecified. But the expressions are no longer transformed since it changed the expected behavior.
2001-11-26 V2.19A (unofficial)
2001-08-24 V2.11C
Program corrections
[GO373] If a complex address expression was used to access a part of a memory word, the optimizer could sometimes fail to recognize that an update to the whole memory word is also an update of the part of the word. If the expression was large enough, in some cases it was erroneously eliminated as a common subexpression and the value before the update was used.
2001-08-10 V2.11B
Program corrections
[V850C0028] Casting of HUGE memory pointers could sometimes go wrong.
[V850C0027] When a variable with attribute 'volatile' was stored in a 'non- volatile' temp variable, compiler sometimes forgot volatile attribute when using variable later.
[V850C0025] Illegal rearrangement of instructions occurred at higher optimization levels.
2001-04-03 V2.11A (Never released)
Program corrections
[V850C0019] Building a release version of project containing an own copy of the putchar routine resulted in linking error:
Undefined external ?C_PUTCHAR.[V850C0018] Compiler generated incomplete _reg_lockXX runtime attribute information.
[V850C0017],[V850C0020],[V850C0021],[V850C0021] A number of problems appearing at high optimization levels has been fixed:
- incorrect code generated
- compiler internal error
2000-06-27 V1.13D
Program corrections
[V000614A] The optimizer did not mark the carry bit as destroyed for sign extension operations (implemented as a SHL/SHR sequence). This could, for example, cause it to be hoisted above a branch instruction. (The (incorrect) code could then be further optimized, causing the branch itself to be optimized away.) Note that this bug only occurs when the -v0 processor option is used.
2000-06-19 V1.13C
Program corrections
- Extended usage of the MULH instruction for expressons like (signed int16)*(signed int16). The use of '?MUL32' library function call is less frequent now.
[V850C0015] Registers used as parameters other than the first six ( R1, R5, R6, R7, R8 or R9 ) were not saved properly between calls.
[V850C0016] If the library function ?Div32s were not used, signed integer division was sometimes incorrect. E.g: Result of -maxint / -maxint was -1 instead of 1.
[LB315] Zero add to volatile variable was optimized away. This would occure at optimization level 3 and above.
- An expression like:
*((unsigned short __huge *)(0xfffe0000+vAddrLine))= 0xFFFF;
would generate an Internal Error. This could be avoided with one of the following workarounds:
WA#1: Rewrite the expression to:*(((unsigned short __huge *)0xfffe0000)+vAddrLine)=0xFFFF;
WA#2: Use a temporary variable:
unsigned short *t; t=((unsigned short *)(0xfffe0000+vAddrLine)); *t=0xFFFF;
[V850C0013]
- Pointer cast could sometimes, erroneously, be ignored. For example:
*(((int __huge *) array) + 80000) = 10;
A workaround is to use a pointer to __huge memory rather than casting a shorter pointer to a __huge pointer. This is normally only visible when array is declared as
int array[...];
rather than
int * array;
[V850C0011]
2000-04-13 V1.13B
Program corrections
- The compiler uses a new global optimizer. Besides better optimization the bugs LB329, LB330 and LB347 are removed with this release of the new global optimizer. The following error messages where generated: LB329:
Internal error: [BeOldFe - SafeToMove]: Diagnostics: expr not handled P0: 0 P1: 0 Fatal error detected, aborting.
LB330:
Internal error: [any]: Unexpected exception Fatal error detected, aborting.
LB347:
Internal Error: [GoCanonicalize::Expression]: Not canonical expression Internal Error: [any]: Unexpected exception
[V850C0014] The instruction scheduler in the compiler could generate incorrect function exit code. The SP would be incremented too early. This would lead to an unprotected stack, which is dangerous, if an interrupt should occur.
[CC323] Debug information for struct types was incorrect when the struct type was used before it was fully defined.
Case 1:typedef struct X * Xp; struct X { int a; };Case 2:
struct test1 { int value; struct test1 *p,*n; };In case 1 the field list was omitted entirely in the object file, which meant that no fields could be inspected in values of type struct X. In case 2 the only field that was included in the object file was the value field, which meant that it was the only one visible in the debugger.
1999-12-07 V1.13A
Program corrections
- Corrected problem that could be triggered by extensive use of inline assembler.
- Use of the default operator new does not cause fputs and related functions to be included in the linked file.
- Code generated to copy stuctures to and from __huge memory erroneously used __near addressing. This could cause a link-time error.
[V850C0009] No instructions are moved over EI and DI by the instruction scheduler.
[V850C0010] The registers R18 and R19 are not touched at any time by the library if the --reg_const option is used by the compiler.
[V850C0008] The registers containing the values 255 and 65535 when the compiler option --reg_const is used is now initialized before __low_level_init is called.
[V850C0007] Access to volatile objects are no longer removed at high optimization levels.
- New error message: [TBe023]: Memory access out of range. (Use pointer to __huge memory instead?) This is generated when the pointer type can't access the memory requested. For example, in the default memory model the following line will generate the error since a __brel pointer can only span 32768 bytes.
*(ptr + 80000) = 10;
The solution is to declare the pointer as __huge. [V850C0006, V850C0012]
See also the section on known bugs above [ref:V850C0011]. [V850C0005] More efficient code is generated for arithmetical operations. E.g. code for signed 16 * 16 to 32 bit operations generates MULH instructions. Division by a power of two generates a code sequence containing a right shift.
1999-10-29 V1.12B
Program corrections
- Compatibility problem with 78K/0, 78K/0S and 78K/IV C source code, regarding type checking of the keyword const, has been corrected.
1999-06-25 V1.12A
Program corrections
[V850C0004] Linking a program using terminal I/O without using the selection: Debug info with terminal I/O generated a program executable which was not simulated correctly by C-SPY. Now a link error is generated, undefined __putchar or __getchar referenced.
[V850C0003] Hidden SFR's are now removed from the I/O include files and the device definition files.
[V850C0002] Bug corrected regarding possible missing save/restore of register R9 in interrupt functions.
[V850C0001] Bug corrected regarding use of bit instructions on non bit accessible SFR registers. A new type attribute, __no_bit_access.