Release History
- V7.20 2014-05-19
- V7.10 2014-02-21
- V6.70 2013-10-29
- V6.60 2013-06-27
- V6.50 2012-11-10
- V6.40 2012-06-05
- V6.30 2011-10-22
- V6.21 2011-07-05
- V6.20 2011-04-29
- V6.10 2010-11-04
- V5.50 2010-04-21
- V5.41 2009-12-14
- V5.40 2009-07-10
- V5.30 2009-01-23
- V5.20 2008-06-24
- V5.11 2007-12-11
- V5.10 2007-06-12
- V4.41A 2006-12-08
- V4.40A 2006-06-03
- V4.31A 2006-02-03
- V4.30A 2005-06-23
- V4.20A 2005-01-10
- V4.11A 2004-06-10
- V4.10B 2004-03-09
- V4.10A 2004-02-21
- V3.40C 2003-12-12
- V3.40B-P1 2004-10-06
- V3.40A 2003-07-03
- V3.30B 2003-03-18
- V3.30A 2003-02-18
- V3.21A 2002-09-27
- V3.20A 2002-06-18
- V3.11A 2001-12-04
- V3.10A 2001-10-02
- V2.10D 2001-06-27
- V2.10A 2001-02-21
- V1.30C 2000-10-14
- V1.30A/B 2000-09-28
- V1.20A 2000-05-28
- V1.10A 2000-01-14
V7.20 2014-05-19
Program corrections- 
  Setting an alignment higher than 16 in a #pragma packdirective can trigger an internal error in the compiler.
 [EW24509]
- 
  The strftimelibrary function intime.hcannot be used in AEABI mode. Further,time.hcan not be included in a C++ source module in AEABI mode.
 [EW24666]
- 
  In EWARM 7.20.2: 
 Loops that rely on integer overflow in the step expression can in some cases be incorrectly optimized.
 [EW24248, EW24256]
- 
  In EWARM 7.20.2: 
 A boolean function call can be incorrectly optimized if its result is used in the expression following immediately after the function call, and that expression also contains an indirect access through a pointer.
 [EW24710]
- 
  In EWARM 7.20.2: 
 whileloops andforloops with an empty step expression can, in some cases, be incorrectly optimized if the last statement in the loop is another loop.
 [EW24742]
- 
  In EWARM 7.20.2: 
 In EC++/C++, whenstdarg.h(orcstdarg) was included before any other standard header,(std::)va_listwas not defined.
 [EW24746]
- 
  In EWARM 7.20.2: 
 In some rare circumstances assignments, to global variables or indirect assignments through pointers, in conditional code can be optimized incorrectly.
 [EW24748]
- 
  In EWARM 7.20.5: 
 Runtime checking for unsigned integer overflow might result in a false positive for pre/post-decrement, due to an intermediate representation as addition with a negative value which in unsigned arithmetic will most often result in overflow.
 [EW24763, EW24851, EW24916]
- 
  In EWARM 7.20.5: 
 In some cases involving syntax errors in string literals, compilation can fail to terminate or terminate with an internal error.
 [EW24806]
- 
  In EWARM 7.20.5: 
 The common sub-expression optimzation sometimes incorrectly changes the inserted bounds checking code into making the compiler produce an internal error.
 [EW24849, EW24853, EW24913]
- 
  In EWARM 7.20.5: 
 A warning message is corrected, changedto complexintotoo complex.
 [EW24869]
- 
  In EWARM 7.20.5: 
 When an auto aggregate is partially initialized by solely non-constant values, the compiler fails to emit code to zero-initialize for the remaining parts of the aggregate.
 [EW24920]
- 
  In EWARM 7.20.5: 
 At the medium optimization level, code can be incorrectly optimized around function calls in conditions. An indirect load that occurs on both paths after the condition can incorrectly be performed before the call.
 For bitfield assignments, other bitfields in the same bitfield container might be reset to the value prior to the call.
 [EW24922]
- None.
V7.10 2014-02-21
Program corrections- 
  The error messages Pa053andPa054now use ELF terminology.
 [EW24093]
- 
  The compiler should issue an error for referring to a struct declared __packedif the struct was not defined with__packed. A warning should be emitted when defining a struct without__packed, if there was a previous declaration with__packed.__packed struct X {...} * x;should not add__packedto bothstruct Xandx.
 This program correction supersedes the note about the temoporary solution of EW24270 in EWARM 6.70.2, which read "IAR extended type attributes before the type in field declarations in C are incorrectly applied to the type instead of the field."
 [EW24270]
- 
  Pre- or post-inc ( ++vorv++) of a variablevplaced in a global register (using#pragma locationor@) would result in internal error.
 [EW24381]
- 
  Generating code for multiplication in Thumb-1 mode could result in internal error. 
 [EW24385]
- 
  In some cases, the compiler can terminate with an internal error when reporting an error involving a function. 
 [EW24387]
- 
  filenoin the DLIB library will return error status for a legitimite file.
 [EW24393]
- 
  The MISRA-C rule 14.10 is not properly checked when using c99. 
 [EW24402]
- 
  The high part of the old value and the low part of the new value could be loaded from a parameter variable smaller than 32 bits, if the parameter was passed on the stack and later updated in place. 
 [EW24429]
- 
  The loop counter could incorrectly be wrapped in memcpy()for ARMv7-M when building with--no_unaligned_accessfor a small unaligned copy, depending on the data being copied.
 [EW24432]
- 
  An assigment from a variable of a structure type to itself can in some cases result in writing to memory immediately following the variable location. 
 [EW24458]
- 
  At medium or higher optimization levels a zero-extend can be hoisted out of a loop when the extended bits are known to be preserved after bitwise logical operations. The optimization is performed also for sign-extend operations, for which the extended bits are not known to be preserved. 
 [EW24459]
- 
  In a very rare situation, related to static clustering, incorrect code might be generated. 
 [EW24464]
- 
  In EWARM 7.10.3: 
 In ARM mode, and in Thumb mode for devices with the Thumb-2 ISA, the backtrace adjustment for the auto-area might be missing or faulty for some rather large sizes of the auto-area. In case this occurrs, C-SPY will show the wrong address for variables placed in the auto-area, for example in the Locals window.
 [EW24499]
- 
  In EWARM 7.10.3: 
 #pragma default_variable_attributeshas no effect on variables with const or volatile type.
 [EW24525]
- 
  In EWARM 7.10.3: 
 MISRA C:2004 rule 14.10 erroneously gives an error for the constructionif (x) f1(); else { if (y) f2(); }.
 [EW24533]
- 
  In EWARM 7.10.3: 
 The compiler can erroneusly report a non-existing violation of MISRA C 2004 rule 14.10 (finalelseafterif...else if) in some cases involving nested if statements.
 [EW24545]
- 
  In EWARM 7.10.3: 
 In some cases the compiler generated code for an expression on the form~x & (y << k)that corresponds tox & ~(y << k). This would occur when anLSLinstruction is replaced by a shifted operand within aBICinstruction, and the operands of theBICinstruction are swapped even though it is not a commutative operation.
 [EW24548]
- 
  In EWARM 7.10.3: 
 When generating code for Thumb-2 a test can go the wrong way for unsigned compare less/greater-than (or equal) if one operand is negated and the value for that operand is zero.
 [EW24561]
- None.
V6.70 2013-10-29
Program corrections- 
  On medium and high optimizations, a pointer variable pcan be optimized incorrectly ifpis assigned the address of an array element, where the index expression is an other array expression or an indirect load, and the value of the index expression changes between the assignment ofpand the use(s) ofp.
 [EW24173]
- 
  In EWARM 6.70.2: 
 When generating code for Thumb1, any stack accesses that either explicitly or through compiler optimizations get a negative offset from SP, will result in an internal error.
 [EW24231]
- 
  In EWARM 6.70.2: 
 Loops containing two or more expressions where the loop variable+/-a constant offset is multiplied with a loop-invariant expression, might be incorrecly optimized if the constant offset differs between the expressions.
 [EW24238]
- 
  In EWARM 6.70.2: 
 A loop-invariant truncating type conversion could incorrectly be hoisted to a location before a use of the value being converted.
 [EW24243]
- 
  In EWARM 6.70.2: 
 When generating code for VFP in Thumb2, if the program contains a code sequece that selects the smallest of two floating point values the compiler might issue an internal error.
 [EW24246]
- 
  In EWARM 6.70.2: 
 Putting a partial update of a local short variable at the end of a loop body or a conditional block can sometimes make the compiler crash.
 [EW24247]
- 
  In EWARM 6.70.2: 
 A sign- or zero-extend operation can be optimized away if a mask is found that creates a value such that the preceding extend has no effect. This can happen also if the mask depends on the extend operation, which then produces the wrong value when the extend is removed.
 [EW24255]
- 
  In EWARM 6.70.2: 
 CSmith found a problem that makes the compiler generate incorrect code.- A packed struct with padding inside just before a bitfield which only uses a part of its container.
- An initializer to a variable of the struct.
- The compiler can deduce the value from the initializer.
 
 If all of the above occurs, the compiler can propagate the wrong value for the bitfield.
 [EW24258]
- 
  In EWARM 6.70.2: 
 On high optimization, masking assignments, likeg &= 1used inside an&&or||condition might be incorrectly optimized if there are no other uses ofginside the function.
 [EW24278]
- 
  In EWARM 6.70.2: 
 Loops with unsigned loop variables that are initialized with negative values might be incorrectly optimized.
 [EW24280]
- 
  In EWARM 6.70.2: 
 Diagnostic column positions can sometimes be incorrect when a complete macro invocation is present earlier on the same line.
 [EW24308]
- 
  In EWARM 6.70.2: 
 In non-strict C89/(E)EC++/C++ modes, unsuffixed integer literals larger thanLONG_MAXbut smaller thanULONG_MAX+1are incorrectly given a type ofunsigned longinstead oflong long. In particular, when used in an expression with the prefix-operator, the result is thus a positiveunsigned longvalue rather than a negativelong longvalue, as would be expected. Example: -2388135082 becomes 1906832214.
 [EW24323]
- 
  In EWARM 6.70.2: 
 The compiler does not generate stack usage analysis information for some virtual function calls when multiple or virtual inheritance is involved.
 [EW24329]
- 
  In EWARM 6.70.2: 
 For code using C++ pointers to data members, an assertion atlower_il.c, line 13418 can trigger erroneously.
 [EW24331]
- 
  In EWARM 6.70.2: 
 A MISRA C rule 5.1 (31 significant characters) violation diagnostic message is erroneously emitted for a program making use of the IAR Systems runtime routines__iar_unaligned___aeabi_memmove4and__iar_unaligned___aeabi_memmove8.
 [EW24337]
- None.
V6.60 2013-06-27
Program corrections- 
  A pointer parameter, cast to an integer type, used in a switch expression no longer causes an internal error during function inlining. 
 [EW23758,EW23941]
- 
  An internal error no longer occurs when compiling C++ with VFP support if there is a flow for C++ exceptions to an interrupt function. 
 [EW23804]
- 
  MISRA-C:2004 rule 5.4 is now supported correctly. 
 [EW23907]
- 
  In some cases when compiling for Thumb2 the compiler did not sign-/zero-extend a 16-bit value as needed before performing a right shift, if the shift count was not constant. This has been corrected. 
 [EW23961]
- 
  The compiler does not change the underlying MISRA-C:2004 type for an explicit Ccast. This can generate erroneous MISRA-C:2004 errors for rules that check against the underlying type.
 [EW23988]
- 
  In EWARM 6.60.2: 
 In a leaf function compiled for Thumb2 at high optimization level, in some cases a comparison between zero and the result of a multiplication could result in faulty code for the comparison if other statements in the function are relatively simple.
 [EW24014]
- 
  In EWARM 6.60.2: 
 Usingmemcpyto modify the content of an automatic variable of a type shorter thanintmight trigger an internal error in the compiler. Example that triggers the problem:
 [EW24037]void f (int *x) { short a; memcpy (&a, 0, 0); if (a == 1 || a == 2) *x = 0; }
- 
  In EWARM 6.60.2: 
 In some very rare cases, two compilations of the same file might not produce identical results.
 [EW24044]
- 
  In EWARM 6.60.2: 
 Reading a 16-bit value from an unaligned source, such as a pointer to packed structure, casting it to the opposite signedness and then casting it to a 32-bit value might produce invalid code.
 [EW24066]
- 
  In EWARM 6.60.2: 
 assert()now generates a message. Note, the behaviour is changed in 6.60.2, read more in Release notes for the IAR C-SPY Debugger for ARM.
 [EW24102]
- 
  In EWARM 6.60.2: 
 Specifying a non-static member function in#pragmacalls results in error Pe028 (expression must have a constant value).
 [EW24137]
- 
  In EWARM 6.60.2: 
 When mangling template names, IAR Systems type qualifiers, like__packed, in template type arguments are not taken into account, which can lead to internal errors in the compiler, errors when linking, or silent use of the wrong code. Example:Given the template The bug leads to problems if the same template is instantiated in such a way that the only difference is in type qualifiers in its template type arguments. Memory qualifiers are correctly taken into account.template<typename T> struct X;bothX<int>andX<int __packed>get the same mangled name.
 [EW24140]
- 
  In EWARM 6.60.2: 
 A left-shift of a masked result (bitwise AND) of a signed right-shift can sometimes be expressed without the right-shift. If the optimization is correct it might still not be performed depending on the order between addresses allocated by the OS.
 [EW24143]
- Advanced heap update 
 Available functionality of the advanced heap is listed in- arm\inc\c\iar_dlmalloc.h. The statistic functions of the advanced heap can be used through this header file.
V6.50 2012-11-10
Program corrections- 
  The calculation of leap days was incorrect in the time system in the library. This has been corrected. 
 [EW23273]
- 
  In some rare cases the compiler could end up in an infinite loop. This has been corrected. 
 [EW23308, EW23573]
- 
  The compiler no longer terminates with an internal error when --macro_positions_in_diagnosticsis used.
 [EW23337]
- 
  Incorrect code was generated for varargs constructors in some cases. This has been corrected. 
 [EW23358]
- 
  The compiler now generates useful stack backtrace also for a non-returning interrupt function. 
 [EW23363]
- 
  The underlying type for the __section_size()(and its alias__segment_size()) operator was erroneous. This could lead to, for instance, MISRA-C:2004 rule10.1 errors if that operator was used. This has been corrected.
 [EW23390]
- 
  The function prologue/epilogue for an interrupt function ( __irqor__fiq) now stores/restores also the VFP registersD16through toD31, when available.
 [EW23418]
- 
  The compiler now generates correct debug information for variables placed on the stack in functions ending with an infinite loop. 
 [EW23422, EW23439]
- 
  If error Pa128(truncating cast in constant expression) was suppressed or turned into a warning when casting from a pointer to a smaller integer, the compiler aborted with an internal error. This has been corrected.
 [EW23444]
- 
  Accesses to volatile auto structs could be incorrectly optimized. This has been corrected. 
 [EW23458]
- 
  Combinations of left shifts, right shifts, multiplications with a power of 2, and divisions with a power of 2 in array index expressions could be incorrecly optimized. This has been corrected. 
 [EW23526]
- 
  An indirect expression through an initialized global or static constpointer could be optimized incorrectly. This has been corrected.
 [EW23543]
- 
  An array index expression could be incorrectly optimized if the index expression was used in a loop (L), and if a variable (V) was assigned a value that was invariant in L, and V occured multiple times in the index expression. 
 [EW23571]
- 
  In EWARM 6.50.2: 
 In some rare cases a static or global variable in nested loops could be optimized incorrectly if an inner loop contained potential aliasing, for example as a function call or indirect accesses, and the variable was modified in both the inner loop and the outer loop. This has been corrected.
 [EW23566]
- 
  In EWARM 6.50.2: 
 Patterns where a pointer to a pointer was used in pointer arithmetics no longer trigger an internal error.
 [EW23579]
- 
  In EWARM 6.50.2: 
 Accesses where the address of an array is cast into a pointer to a data type larger than the element type and several array elements are accessed at once, no longer trigger an internal error.
 [EW23581]
- 
  In EWARM 6.50.2: 
 For Cortex-M4F, the standard library calllongjmpnow restores the VFP registers correctly.
 [EW23583]
- 
  In EWARM 6.50.2: 
 The__iar_Mutexno longer allocates a lock in the normal library.
 [EW23584]
- 
  In EWARM 6.50.2: 
 An address of an auto variable cast tovoidno longer trigger an internal error.
 [EW23602]
- 
  In EWARM 6.50.2: 
 Right shift (arithmetic as well as logic) no longer cause theZeroExtproperty to become negative.
 [EW23613]
- 
  In EWARM 6.50.2: 
 The filesdata_init.c(replacingdata_init3.c) andrle_init.c(replacingrle_init3.c) are no longer missing from the IAR Embedded Workbench installation.
 [EW23616]
- 
  In EWARM 6.50.3: 
 Partial assignments in the initialization of loop variables could trigger an internal error. This has been corrected.
 [EW23634]
- 
  In EWARM 6.50.3: 
 In ARM mode, a signed comparison of a shifted value with 0, for example(x >> 16) < 0, could result in an internal error. This has been corrected.
 [EW23665]
- 
  In EWARM 6.50.3: 
 The media instructionSMMULwas incorrectly generated for unsigned (zero-extended) operands. This has been corrected.
 [EW23682]
- 
  In EWARM 6.50.3: 
 The header fileinit_streams.his now included in the library source code shipped with the full product.
 [EW23709]
- 
  In EWARM 6.50.3: 
 Now the MISRA-C:2004 rule 12.7 uses the underlying type to determine whether the rule has been violated.
 [EW23717]
- 
  In EWARM 6.50.4: 
 An indirect assignment could be optimized incorrectly if the right hand side expression was masked with a constant and the only use was in a test, comparing the value, possibly masked with the same constant as in the assignment or a constant with fewer bits set, to zero. For example:
 p->foo = x & 0x02;
 ...
 if (p->foo & 0x02)
 This has been corrected.
 [EW23796]
- 
  In EWARM 6.50.4: 
 Loops that contains indirect assignments where the address expression consists of both loop dependent variables and loop invariant variables could be optimized incorrectly if the loop was followed by an assignment to the same address expression. This has been corrected.
 [EW23815]
- 
  In EWARM 6.50.6: 
 When compiling for Thumb2 with High optimization level (-Oh,-Ohs, or-Ohz), if the value of aswitchexpression had additional uses after it was evaluated, these uses could in some rare cases yield some other value.
 [EW23873]
- 
  In EWARM 6.50.6: 
 When using a string literal to initialize an array and the string literal contained too few bytes, the compiler did not initialize the last bytes of the array properly. The missing bytes were read from after the string literal. This has been corrected.
 [EW23891]
- None.
V6.40 2012-06-05
Program corrections- 
  Using 16-bit and 8-bit integer variables as bitfields no longer causes an internal error. 
 [EW22858]
- 
  In some rare cases the compiler could loop when compiling a signed expression containing multiple shifts. This no longer happens. 
 [EW22896]
- 
  Using multi-file compilation, --mfc, with files that use inline assembler statements could result in an internal error.
 [EW22905]
- 
  In some rare cases the stack frame of a function could be optimized in such a way that the debug information would be erroneous (off by four, for example). This means that in the debugger, a stack variable could appear to reside in some location which will probably not hold the expected value. This no longer happens. 
 [EW22907]
- 
  A module containing a pointer to a member function constant for a virtual function could in some cases result in a symbol_lookup_M31internal error in the compiler for the typeinfo object for the owning class.
 [EW22918]
- 
  A volatile load could incorrectly be removed if it was part of an expression that was shifted so far that none of the bits from the load were used. 
 [EW22974]
- 
  An asmstatement following immediately after a constructor call caused an internal error.
 [EW22982]
- 
  A Common subexpression elimination (CSE) was erroneously lifted due to faulty bitfield handling. This has been fixed. 
 [EW22988]
- 
  Fixed a problem with using #pragma call_graph_rooton a__weakfunction definition. In Thumb mode, the result was an internal error in the compiler. In Arm mode, the result was that the linker in some cases used a section symbol (something like.text_17) instead of the function symbol for these functions.
 [EW22996]
- 
  An asmstatement containing a local label in a function in a module where the function is inlined twice produced an internal error. This has been fixed.
 [EW23006]
- 
  The compiler no longer generates ITinstructions insideITblocks, which caused an internal error.
 [EW23020, EW23083]
- 
  Using the address of a C99 compound literal to initialize a pointer in an aggregate caused an internal error in the compiler. 
 [EW23021]
- 
  In some rare cases partial accesses were incorrectly optimized. 
 [EW23028]
- 
  The compiler had a bug that could cause the display of stack-allocated local variables to be incorrect in debuggers other than C-SPY. 
 [EW23042, EW23047]
- 
  Now an unsigned longto anunsigned intcast in a static initializer does not generate an error.
 [EW23054]
- 
  The compiler, the linker, and the elftools returned error status when run without options. This has been fixed. 
 [EW23057]
- 
  The cross call optimization could not handle a sequence that started with a label and had one back-jump to that label in the sequence and one back-jump to it after the sequence. This has been fixed. 
 [EW23063]
- 
  Inline assembler expressions with volatile arguments could fail in register allocation. 
 [EW23086]
- 
  In some cases a common subexpression could be hoisted across a condition controlling the execution of the expression. 
 [EW23087]
- 
  Index expressions mixing signed and unsigned types could in some rare cases cause an internal error. 
 [EW23088]
- 
  The compiler could erroneously inline __weakfunction definitions.
 [EW23112]
- 
  C-SPY no longer generates an error when the debugged application contains a C symbol with the name c or d. 
 [EW23131]
- 
  The choice of using the 64-bit implementation for the time interface did not work when using low optimization levels. This has been fixed. 
 [EW23162]
- 
  The compiler issued an internal error when checking the code (void (**)(void)) 1for violation of the MISRA C:2004 rule 17.5. This has been fixed.
 [EW23164]
- 
  The linker now selects the correct libraries when linking an application without code, also for Cortex-M devices. 
 [EW23204]
- 
  For Thumb2, at optimization level Medium, expressions of the form (x >> K) & Mcould result in code that cleared too many bits (for a constantK > 0andM = (1 << N) - 1for a constantN > 0).
 [EW23214]
- 
  The endian attribute for pointers and arrays is now supported in the compiler, which makes this issue obsolete. 
 [EW23220]
- 
  Fixed a pathological case where a static variable used as index expression in a static array could trigger an internal error. 
 [EW23229]
- 
  In EWARM 6.40.2: 
 TheLDRDinstruction could be used for copying an 8-bytestructwith less than 4-byte alignment, which could result in an exception (hard fault) when running the application. This no longer occurs.
 [EW23272]
- 
  In EWARM 6.40.2: 
 When compiling for Thumb2, a zero-initializer for a single byte array on the stack no longer generates code that clears two bytes of memory.
 [EW23298]
- 
  In EWARM 6.40.3: 
 A bitwise AND (&) between an 8-bit variable and a constant wider than 8 bits does no longer generate an internal error.
 [EW23295, EW23362, EW23365]
- 
  In EWARM 6.40.3: 
 In some rare cases multiple tests of the same variable could be incorrectly optimized. This has been corrected.
 [EW23360]
- 
  In EWARM 6.40.3: 
 At optimization level medium (or higher), the updates of an address passed to the__PLDor__PLIintrinsic functions could be optimized away. This has been corrected.
 [EW23387]
- 
  In EWARM 6.40.4: 
 Loops with multiple exit tests (a test containing&&or||counts as multiple tests) could be optimized incorrectly, if one test tested a loop counter, another test tested a value loaded indirectly from a pointer, and the pointer was incremented or decremented on each iteration through the loop.
 [EW23318]
- Inline assembler 
 New operand constraints and modifiers.
- CMSIS update 
 CMSIS version 3.01 is now included in the product.
V6.30 2011-10-22
Program corrections- 
  The diagnostic messages now refer to the correct rule numbers when MISRA C 2004 is chosen. 
 [EW22347]
- 
  The underlying type of a constant expression is now evaluated as for any other expressions. This deviates from the specific constant expression rule in MISRA-C:2004 6.10.4. Both IAR Systems and the MISRA-C committe feels that this rule doesn't reflect the intention. 
 [EW22373]
- 
  Initalizing a member chararray with a string literal in a class constructor no longer results in an internal error.
 [EW22503]
- 
  The intrinsic function __REV16is now available when compiling for Cortex-M0.
 [EW22715]
- 
  Complement ~of an unsigned expression is no longer optimized incorrectly when the expression contains a right shift or a bitwise and with a constant.
 [EW22725]
- 
  C++ temporary objects needed when initializing file-scope and namespace-scope variables are now created properly. 
 [EW22751]
- 
  A signed test for less than, less equal, greater than or greater equal on an expression that is shifted immediately before the test now gives correct result. 
 [EW22752]
- 
  In EWARM 6.30.3: 
 Using the__packedattribute in situations that involve template functions no longer causes an internal error.
 [EW22776]
- 
  In EWARM 6.30.3: 
 On the high optimization level, a mix of signed and unsigned values in complex array index expressions no longer causes an internal error.
 [EW22787]
- 
  In EWARM 6.30.3: 
 Passing a constant as argument to an intrinsic function that inserts a specific assembler instruction no longer causes an internal error in C++ mode.
 [EW22808]
- 
  In EWARM 6.30.3: 
 In rare cases the induction variable optimization could cause an internal error. This has been corrected.
 [EW22815]
- 
  In EWARM 6.30.3: 
 Using the multi-file compilation option--mfcwith one or more zero-size source files no longer causes the compiler to terminate with an internal error.
 [EW22828]
- 
  In EWARM 6.30.3: 
 The debug information in ELF files now refers to the correct source file name when the command line option--preincludeis used.
 [EW22848]
- 
  In EWARM 6.30.3: 
 When some diagnostics (in particular, the undefined behavior warnings about unordered accesses etc) were triggered on uses of fields in a block-local anonymous struct/union variable, the compiler aborted with an internal error. This problem has been corrected.
 [EW22850]
- 
  In EWARM 6.30.3: 
 The thread-exit function now correctly deallocates the potentially allocated daylight saving time structure.
 [EW22862]
- 
  In EWARM 6.30.3: 
 An instructions inside an IT-block is no longer a candidate for dead-code removal, since removing it will leave the IT-instruction inconsistent.
 [EW22864]
- 
  In EWARM 6.30.5: 
 Common subexpression elimination (CSE) could go wrong in rare cases when equivalent bitwise or-expressions occurred at multiple locations, and at least one but not all were rewritten as a bitfield instruction. This no longer happens.
 [EW22932]
- 
  In EWARM 6.30.6: 
 A function containing two? :expressions (or equivalentifstatements) with identical tests where two different variables were assigned the same values could be optimized incorrectly if the first variable was reassigned in the basic block following the? :expression. This has been corrected.
 [EW22965]
- 
  In EWARM 6.30.6: 
 The compiler could incorrectly optimize the expressionuchar = ~0 (int & 1). This has been corrected.
 [EW22972]
- 
  In EWARM 6.30.8: 
 Some assignments could be incorrectly optimized if the left-hand side was an indirection (through a pointer or reference) or a global or static variable and the right-hand side was a function call. Exceptions thrown from those calls were not correctly handled.
 The optimization intra cross jump did not always create correct code when one of the sequences it tried to optimize was exception code. This has been fixed.
 [EW23094, EW23185]
- 
  In EWARM 6.30.8: 
 Range checks, such as((unsigned char) x)-48 < 10, could sometimes be performed without zero-extending the variablex.
 [EW23141]
- None.
V6.21 2011-07-05
New features- None.
- 
  Location information (from #pragma locationor the@operator) now carries over properly from a function declaration to the function definition.
 Example:
 int foo(void) @ "XXX";The function
 int foo(void) { return 1; }foo()should be placed in the sectionXXX, but it was not.
 [EW22448]
- 
  Redeclaring mainwith non-matching location strings and suppressing the resulting error caused an internal error in the compiler. Now the error cannot be suppressed in this situation.
 [EW22450]
- 
  Commutative operations with multiple constants are no longer optimized incorrectly even if one or more of the operations is of a smaller type. 
 [EW22470, EW22484]
- 
  For a nested interrupt handler, LRis now adjusted.
 [EW22472]
- 
  String literals in inline and template functions were turned into non-const variables. Now the variables are constinstead, and end up in ROM, the way they should.
 [EW22475]
- 
  Corrected an internal error. 
 [EW22479]
- 
  In EWARM 6.21.4: 
 For certain small switch statements the compiler generated different code for different invocations. This has been fixed.
 [EW22520]
- 
  In EWARM 6.21.4: 
 In some rare cases a store to a struct member in an auto object was optimized incorrectly if the object member was read once before the address of the object was passed to a function.
 [EW22537]
- 
  In EWARM 6.21.4: 
 The compiler now avoids widening partial definitions.
 [EW22539]
- 
  In EWARM 6.21.4: 
 When the Thumb-1 instructionADD.N Rdn,Rdn,SPis widened the equivalent Thumb-2 instructionADD.W Rdn,SP,Rdnis used, sinceADD.W Rdn,Rdn,SPis unpredictable.
 [EW22555]
- 
  In EWARM 6.21.4: 
 The compiler no longer places too many constants or string literals between a branch and its target, which for a Thumb-1 function whereLRis not pushed could result in "Internal error: Jump distance to far for B".
 The compiler also no longer places too many constants or string literals between anADRinstruction and its target, which could result in "Internal error:[AsmLine - OgAsm]: Error[400]: Expression out of range".
 [EW22611]
- 
  In EWARM 6.21.4: 
 The compiler no longer crashes when compiling a reference toASR,LSR,LSL,ROR, orRRX.
 [EW22614]
V6.20 2011-04-29
New features- time.hhas an optional 64-bit interface that supports years from -9999 up to 9999. For more information see the Development guide.
- 
  When compiling a C file with the --use_c++_inlineoption, the C99 rule that a public inline function definition cannot reference functions or variables with internal linkage is no longer checked.
 [EW22161]
- 
  Loops where the final statement in the loop body is a switch will no longer trigger an internal error on High optimization. 
 [EW22183]
- 
  The C++ C system headers ( errno.h, etc) can now be included inside anextern "C"block.
 [EW22188]
- 
  A whileloop with multiple returns in the loop body will no longer trigger an internal error.
 [EW22195]
- 
  Now the compiler can handle macro parameters that contains multibytes. 
 [EW22214]
- 
  Compilation of modules with a very large number of constant data symbols is now considerably faster. 
 [EW22243]
- 
  When the offsetofmacro is used in a macro argument for a user-defined macro, the compiler no longer produces unwanted warnings about the contents of theoffsetofmacro.
 [EW22250]
- 
  The symbol __vector_tableis now included when linking with the filearm\src\lib\thumb\cstartup_M.cdelivered with the product.
 [EW22252]
- 
  The compiler now correctly handles multibyte characters in a comment and the source line splice mechanism. 
 [EW22276]
- 
  The unrolling of a one-trip loop with multiple tests and empty loop body now works also when the second test is used to determine that only one iteration of the loop shall be executed. 
 [EW22295]
- 
  Complex expressions involving left-shifts and subtractions will always be optimized correctly. 
 [EW22306]
- 
  In some cases the compiler could generate a Thumb-2 ADDinstruction with negative 8-bit immediate, which the assembler would convert to a narrowThumb-1SUBinstruction. This has been corrected.
 [EW22308]
- 
  MISRA C rules were erroneously applied to the constant expression for the address in a #pragma locationor after the@operator, resulting in spurious diagnostics when MISRA C checking was enabled. This has been corrected.
 [EW22321]
- 
  The compiler no longer produces an internal error when generating code for Thumb-2 and trying to split a 64-bit store into two 32-bit stores (for example due to alignment) when the address operand is of the form [<Rn>,<Rm>,#<imm>].
 [EW22324]
- 
  Now the compiler can produce an error for a nonstandard implicit cast of a function to a pointer-to-member. 
 [EW22337]
- 
  Trampoline functions __iar_via_rw_<Rn>are now generated as a writable section fragment, so that__ramcodefunctions can be used also in cases were such a function is needed.
 [EW22346]
- 
  In EWARM 6.20.2: 
 The compiler no longer exits with internal error when optimizing conditional jumps.
 [EW22404]
- 
  In EWARM 6.20.2: 
 For cores with media extensions, the compiler no longer generatesADDinstead of{S,U}XTA{B,H}.
 [EW22407]
- 
  In EWARM 6.20.2: 
 The compiler no longer reports internal error when generating code for Thumb-2 and trying to split a 64-bit load into two 32-bit loads (for example due to alignment) when the address operand is of the form[<Rn>,<Rm>,#<imm>].
 [EW22415]
- 
  In EWARM 6.20.2: 
 In static initialization of a structure or an array of structures, fields following an unnamed bit-field no longer get incorrect values.
 [EW22416]
- 
  In EWARM 6.20.2: 
 The compiler erroneously issued warning Pe021 (type qualifiers are meaningless in this declaration) when using the keyword__packedon a struct or class definition.
 [EW22417]
- 
  In EWARM 6.20.2: 
 Loops withgotostatements no longer trigger an internal error for any case.
 [EW22420]
- 
  In EWARM 6.20.2: 
 The compiler no longer abort with an internal error for aggregate initializers consisting entirely of constant integers in some cases involving non-integer, non-aggregate types nested more than two levels down in the unspecified parts of the initializer.
 [EW22424]
- 
  In EWARM 6.20.3: 
 When generating Thumb-2 code, access to 32-bit floating point values on a large stack frame no longer causes internal error.
 [EW22439]
- 
  In EWARM 6.20.3: 
 Pointer constants involving a cast from an integer could get an incorrect type, leading to spurious errors or internal errors. This has been corrected.
 [EW22441]
V6.10 2010-11-04
New features- The product now uses the current C standard defined in 1999, known as C99, as the default C language. The previous major version of the product used the former C standard defined in 1989, known as C89. C89 can still be used in the compiler by using the - --c89option. The product will not be totally backwards-compatible though, because the support for some C99 features has been withdrawn. Variable length arrays, VLAs, in C99, are not supported in the default C language. They can be enabled with the option- --vla. The C library supports all C99 functionality, and more, but only if used with the C99 language or with any C++ language. If used with the C89 language, C99-added functionality will not be allowed.
- The implementation of EC++ and EEC++ has not changed in any major way. 
- Support for the C++ language has been added. By default, it fully supports the 2003 C++ standard, but can be used with exceptions and/or runtime type information disabled by using - --no_exceptionsand- --no_rttirespectively.
- Thread-safe libraries 
 The DLIB library now supports being used in a threaded environment. Some library systems, like the heap and the file structure, will be guarded by locks. Other library systems, like- localeand- errno, will have their static data allocated in thread-local storage. The DLIB thread support can either be supported by your chosen RTOS or can be manually implemented. For more information see the Development guide.
- The compiler and assembler now automatically know where the library's system headers reside. You can control the compiler using the options: - --dlib_config, to choose a configuration in the DLIB library.
- --system_include_dir, to override the directory to use as system header base.
- --no_system_include, to turn the automation off.
 
- The compiler can now optimize some floating-point expressions more agressively by using the option - --relaxed_fp. If enabled, the compiler tries to reduce the floating-point type used in floating-point expressions. This can cause a small loss of accuracy.
- 
  The library function fpclassify()handles normal and subnormal numbers correctly.
 [EW21098]
- 
  Small memcpycalls are no longer transformed to assignments unless both the source and destination addresses have correct alignment.
 [EW21193]
- 
  The compiler now checks that different kinds of variables are no placed in the same section. 
 [EW21351]
- 
  An internal error should no longer occur if __segment_begin()or__segment_end()is used in conditional code.
 [EW21770, EW21838, EW21905]
- 
  Loops that decremented an unsigned loop counter past zero could in some cases be incorrectly optimized. 
 [EW21795]
- 
  Now all system headers do not generate MISRA errors. 
 [EW21799]
- 
  When optimizing, the the compiler now handles an initializer containing a function pointer with an offset. 
 [EW21870]
- 
  The endian attribute is not supported for pointers or arrays. Now an endian attribute can no longer be specified for pointers or arrays. 
 [EW21887]
- 
  Reversal of byte order is now correctly performed also for combinations of endian attributes and unaligned accesses. Previously, this was in some cases not handled. 
 [EW21888]
- 
  At optimization level High, speed-optimizing small loops similar to 
 could in some cases be incorrectly unrolled and cause an internal error.int test(int n) { while (n-- > 0) if (!foo(n)) break; return n; }
 [EW21949]
- 
  A class with a member that is a nameless struct, or an array of nameless structs, where at least one of the members is not a PoD, could cause an internal error while compiling. 
 [EW21958]
- 
  A while loop with a preincrement or predecrement in the loop test could be incorrectly optimized if the final part of the loop body was a do loop. 
 [EW21999]
- 
  The compiler will no longer merge instruction sequences (through cross call or cross jump optimizations) that are not equal, due to the register operand of a Thumb-2 compare-and-branch instruction ( CBZorCBNZ).
 [EW22000]
- 
  When an enumis specified as a parameter or return type before it has been defined, the compiler will no longer record the wrong num size (attributeTag_ABI_enum_size) in the ELF file.
 [EW22013]
- 
  In Thumb-2, the compiler no longer issues an internal error in an attempt to widen MULS.NtoMULS.W(which is not a Thumb-2 instruction) to achieve a 4-byte alignment of a following instruction or label.
 [EW22018]
- 
  The compiler can now handle a function symbol as an argument to compiler optimized functions like memcpy.
 [EW22052]
- 
  In EWARM 6.10.2: 
 Nestedforloops where the inner loop's initial or final value was the outer loop's variable, multiplied with a constant scaling factor or with a constant offset, no longer causes an internal error on high optimization.
 [EW22078]
- 
  In EWARM 6.10.2: 
 Somewhileloops with multiple exits no longer causes an internal error on high optimization.
 [EW22080]
- 
  In EWARM 6.10.2: 
 Constant data is now placed in the.rodatasection if the compiler has not generated a directADRreference. If there is anADRreference, the constant data is placed in the.textsection.
 [EW22081]
- 
  In EWARM 6.10.2: 
 Standard C++ is now enabled also for the kickstart products.
 [EW22089]
- 
  In EWARM 6.10.2: 
 Now the MISRA-C:2004 rule 20.2 checker can handle a long preprocessor symbol define.
 [EW22117]
- 
  In EWARM 6.10.2: 
 For Cortex-M3, the compiler no longer attempts to generate a sub-routine for identical instruction sequences (cross-call) that end with a call to a software interrupt function (SWI), which would result in an internal error.
 [EW22118]
- 
  In EWARM 6.10.2: 
 The compiler no longer removes code that uses the result of anSTREXinstruction (the instruction can be generated by using the__STREXintrinsic function).
 [EW22119]
- 
  In EWARM 6.10.2: 
 The compiler no longer uses a signed 16-bit value as the immediate operand for theMOVTinstruction. A 16-bit unsigned value is used instead, becauseMOVTexpects an immediate value between 0 and 65535.
 [EW22121]
- 
  In EWARM 6.10.2: 
 Evaluating a function address without using the result no longer causes an internal error.
 [EW22146]
V5.50 2010-04-21
New features- 
        The following C library floating-point functions, for devices without VFP, have been optimized for speed and size: 
 sqrt,sqrtf,modf,modff,fabs,fabsf,fmod,fmodf,floor,floorf,ceil,ceilf,ldexp,ldexpf,frexp,frexpf.
- 
        The following C library floating-point functions, for devices with VFP, have been optimized for speed and size: 
 sqrt,sqrtf,modf,modff,fabs,fabsf,fmod,fmodf,floor,floorf,ceil,ceilf,ldexp,ldexpf,frexp,frexpf,asin,asinf,acos,acosf,atan,atanf,atan2,atan2f.
- 
          While optimizing a function that contained code that prevented the end of the function to be reached, the compiler would erroneously leave a label after the last reachable instruction. This label was later interpreted as a leak of flow-of-control out of the function and an internal error was generated. 
 [EW21541]
- 
          A call to the map index operator now default-constructs the value if the key is not found even for base types. 
 [EW21592]
- 
          Using designated initializers (a C99 feature available in EC++ when IAR extensions are enabled) with a static storage duration object that needed C++ dynamic initialization could cause incorrect initialization. 
 [EW21649]
- 
          The use of intrinsics for LDCandSTCcould in some cases crash the compiler (access violation).
 [EW21657]
- 
          A function, f, updating a global variable, could be incorrectly optimized, if
 - fhad multiple return statements,
- at least one of the return statements was inside a loop, and
- fwas inlined in another function.
 
- 
          For a function call where the compiler inserts a call to memcpyto construct a stack parameter, the registerR1is no longer assumed to survive the call tomemcpy.
 [EW21668]
- 
          The compiler no longer generates unaligned memory accesses for Cortex-M0. 
 [EW21687]
- 
          The compiler no longer generates branch instructions without size specifiers ( .Wor.N) for Thumb-2 capable cores (in Thumb mode), because doing so sometimes could result in an internal error.
 [EW21699]
- 
          In EWARM 5.50.5: 
 Using an enumerator constant directly as a floating-point value no longer produces a corrupt value.
 [EW21704]
- 
          In EWARM 5.50.5: 
 Array pointer decay of a block local static array with template parameter dependent size no longer results in an internal error.
 Example:
 template[EW21728]struct Q { C * get() { static long x[sizeof(C)]; return (C *)x; } }; 
- 
          In EWARM 5.50.5: 
 The instruction scheduling for ARM11 no longer issues an internal error when scheduling aPKHBTinstruction with a shifted operand.
 [EW21745]
- 
          In EWARM 5.50.5: 
 TheUSATinstruction (for unsigned saturation) is now generated with correct bitwidth also in Thumb-2 mode (was off by one).
 [EW21768]
- 
          In EWARM 5.50.5: 
 Cast fromdoubletolong longno longer generates faulty values for very large inputs with a non-zero fractional part. Values in the range [2^32, 2^52] were affected.
 [EW21786]
- 
          In EWARM 5.50.5: 
 An internal error no longer occurs for conditions where the test is a? :expression on the form:
 if ((condition1 && condition2) ? 1 : 0)
 [EW21807]
- 
          In EWARM 5.50.5: 
 Range checks for the address of a function parameter is now translated correctly: it could earlier in some cases result in internal error.
 [EW21826]
- 
          In EWARM 5.50.5: 
 The compiler is now able to inline a function that in its body calls a function with the__noreturnattribute.
 [EW21841]
- 
          In EWARM 5.50.7: 
 An internal error is no longer issued when multiple constant-table references are placed in the same IT-block for a function that is so large that anLDR (immediate)instruction cannot reach outside the function.
 [EW21968]
- 
          In EWARM 5.50.7: 
 Loops that contain conditional accesses through an invariant pointer variable are no longer incorrectly optimized.
 [EW21992]
- 
          In EWARM 5.50.7: 
 A signed division of an expression with a negative divider no longer gets optimized into using an unsigned division.
 [EW22043]
V5.41 2009-12-14
New features- None.
- 
  cstartup_M.cnow includes default interrupt handlers.
 [EW21314]
- 
  Expressions on the form 
 if (expr < 0) v = -expr;
 are no longer optimized incorrectly.
 [EW21340]
- 
  A test inside a loop is no longer optimized incorrectly if 
 a) the loop had constant values for the initial and the final iteration,
 b) the test compared an expression to a constant, and
 c) the calculation of the expression would overflow or underflow for either the initial or final iteration.
 [EW21363]
- 
  Complex |-expressions no longer cause infinite loops during optimization. 
 [EW21380]
- 
  Registers might be spilled to the stack frame when there are more live variables than registers. A spilled large register parameter (more than 8 bytes) no longer results in an internal error. 
 [EW21386]
- 
  The linker is now more relaxed concerning attribute checking when linking with explicitly specified libraries. 
 [EW21387]
- 
  Absolute addressed variable accesses no longer loose the volatileattribute during optimization.
 [EW21400]
- 
  Debug information for classes inheriting from a base class whose primary base was inherited virtually is no longer generated incorrectly. The old problem could result in incorrect display of base classes in C-SPY. 
 [EW21411]
- 
  An error from the assembler in inline assembler code is no longer reported as a compiler internal error. 
 [EW21436]
- 
  The compiler now encodes the character value 255 in a string literal using an escape sequence, to work around the fact that the assembler interprets such a value as end of file. 
 [EW21443]
- 
  Registers are no longer renamed in situations where unused registers become used after renaming, to avoid situations where such registers would not be saved on the stack. 
 [EW21449]
- 
  The compiler now generates correct code instead of reporting an internal error in situations where an entry in a constant table is duplicated so that it can be reached by all its references. 
 [EW21471]
- 
  In EWARM 5.41.2: 
 Integral expressions in loops are no longer optimized incorrectly when the expression adds or subtracts a constant to/from a variable(x + ... + C), and the variable is assigned the same constant subtracted/added from/to the loop index variable(x = i - C).
 [EW21493]
- 
  In EWARM 5.41.2: 
 Two tests on the form
 expr1 > c1 && expr2 < c2
 or
 expr1 < c1 || expr2 > c2
 are no longer incorrectly optimized as a range test whenexpr1is not identical toexpr2.
 [EW21498]
- 
  In EWARM 5.41.2: 
 A bitwise and operation between a constant and a value loaded from memory will sometimes be transformed into a truncated load, which loads only a part of the variable from memory. For a 64-bit variable (in other words,long long) the truncated load will no longer result in an internal error.
 [EW21517]
- 
  In EWARM 5.41.2: 
 Complex array index expressions in loops no longer result in an internal error.
 [EW21545]
- 
  In EWARM 5.41.2: 
 Types smaller that 32 bits must sometimes be sign- or zero-extended before being compared (using for exampleCMP,TST, orTEQ). Sign- and zero-extends are now generated when needed also for cases when the result of bitwise and/xor operations are compared with zero (in other words, cases for which aTSTorTEQinstruction is generated).
 [EW21550]
- 
  In EWARM 5.41.2: 
 Correct values are now produced when the intrinsics__CLZ,__REV, or__REVSHare used with a constant argument.
 [EW21561]
V5.40 2009-07-10
New features- None.
- 
  An if-then-else statement could be optimized into a question mark expression even at low optimization levels, which would make the debugger confused as to which is the current statement. The optimization has now been disabled at optimization levels 'low' and 'none'. 
 [EW20828]
- 
  The compiler no longer generates a message for the usage of long longin system headers even though the options--strict_ansiand--warnings_are_errorsare used.
 [EW20844]
- 
  The final value of variables in loops transformed into a memcpyormemsetcall could, in some cases, be off by one.
 [EW20886]
- 
  Fixed an internal error in the compiler when trying to match an out-of-line template member function definition to the correct declaration. The problem occurred when two or more template member functions differed in the this qualifiers of a pointer to member function type parameter. 
 Example:struct X { templateint fun(Y (Z::*fp)()); template int fun(Y (Z::*fp)() const); }; template int X::fun(Y (Z::*fp)()) { return 1; } 
- 
  The MISRA C error Pm020was incorrectly reported as a warning and the corresponding rule number was omitted from the error message.
 [EW20925]
- 
  When compiling multiple input files ( --mfc) in Embedded C++ mode, the compiler could get an internal error[assertion failed at: ".\src\parser\edg\lower_il.c", line 2484]in some circumstances.
 [EW20927]
- 
  Loops where a global variable ( g) just held a result (gpassed no value between loop iterations) could in some cases be incorrectly optimized.for (...) { g = ... if (...) break; g = ... }[EW20952]
- 
  The compiler and assembler produced object files where group section header table entries did not appear before the entries of all their members, as required by the ELF format. 
 [EW20988]
- 
  After a memcpycall, where a buffer (b) was assignedncharacters from a string literal of lengthn(all characters except the zero termination), ab[n] = 0assignment could erroneously be removed.
 [EW20991]
- 
  Associative expressions containing both a division and a modulo operation could in some rare cases be incorrectly optimized. 
 [EW21010]
- 
  When compiling EEC++ for Thumb, a class that inherits from three or more classes where a virtual method has three or more arguments, one of the generated thunks was faulty (when compiling with multiple inheritance there is sometimes a need for a piece of code that adjusts the 'this' pointer. This piece of code is known as a 'thunk'). 
 [EW21014]
- 
  For a struct xof 8 bytes or more, allocated as a register variable with two fieldsaandb, a simple if statement that can be reduced to a question mark expression (such asx.a < x.b ? x.a : x.b) could result in an internal error.
 [EW21017, 21108]
- 
  Member accesses to auto structs assigned with memcpycould in some cases be incorrectly optimized.
 [EW21020]
- 
  When compiling for VFP, a function call with a variable argument list where an argument passed on the stack is converted from doubletointcould result in an incorrect stack pointer value.
 [EW21023]
- 
  When compiling with --legacy RVCT3.0for Thumb mode, and a constant is shared between functions of the same compilation unit, the compiler could in some cases generate one of the functions in a segment part with two bytes alignment. Four bytes alignment is required in such cases to correctly resolve theR_ARM_THM_PC8relocation.
 [EW21031]
- 
  The code generator could fail to detect that an object had been placed with stricter alignment than required by the type. This would, in turn, cause the compiler to crash when the code generator at a later stage expected the higher alignment. 
 [EW21059]
- 
  When a switch statement inside a loop is generated as a table with negative offsets, the same register could be reused for two different purposes at table lookup. 
 [EW21100]
- 
  The compiler could terminate with an internal error in some cases involving enum types defined in a template class. 
 [EW21101, 21112]
- 
  When optimizing loops where the loop limit is the result of an expression involving possibly negative values in a bitwise AND operation, the compiler could in some cases erroneously conclude that the loop body would execute at least once and eliminate the test of the initial iterator value against the limit. The result of this is incorrect loop code for the case when the loop body should not be executed at all. 
 [EW21118,21120]
- 
  In EWARM 5.40.4: 
 The runtime library no longer assumes that unaligned access is supported in Cortex-M0 or Cortex-M1.
 [EW21262]
- 
  In EWARM 5.40.4: 
 Scalar stack parameters smaller than 32-bit are now properly sign- or zero extended before the function is called.
 [EW21271]
- 
  In EWARM 5.40.4: 
 Compilation of a file using either of the intrinsics__get_interrupt_stateor__set_interrupt_stateno longer results in an internal error.
 [EW21272]
- 
  In EWARM 5.40.4: 
 MISRA C is now available in EWARM-CM.
 [EW21324]
- 
  In EWARM 5.40.4: 
 The compiler now generates correct debug information for calls to C++ member functions defined in another module. The step into debugger command for such a call now works properly.
 [EW21327]
V5.30 2009-01-23
New features- __task extended keyword
 By default, functions save the contents of used preserved registers on the stack upon entry, and restore them at exit. Functions that are declared__taskdo not save all registers, and therefore require less stack space. This is typically used by realtime operating systems.
- 
        Creating a variable with a class/struct/union type with type errors in one or more of its fields could earlier result in an internal error. This has been corrected. 
 [EW20367]
- 
        In some unusual cases the compiler could terminate ungracefully. Ungraceful terminations are now prevented. 
 [EW20380]
- 
        Stack usage reported in the listfile is now again a safe approximation. 
 [EW20410]
- 
        In some cases two pre/post increment/decrements in two consecutive expressions could cause an internal error. This problem has been corrected. 
 [EW20419]
- 
        Irregular loops could in some rare cases be optimized incorrectly. This problem has been corrected. 
 [EW20428]
- 
        Specifying a designated initializer on a field inside more than one level of anonymous unions/structs could earlier cause an internal error in the compiler. This problem has been corrected. 
 [EW20439]
- 
        An inline-assembler operation can now correctly generate an error for absolute addressing in ELF. 
 [EW20489]
- 
        The compiler could fail when generating code for certain loop constructs. This has been corrected. 
 [EW20503]
- 
        In some cases an address expression inside two nested loops could use a variable before it had been assigned a value. This has been corrected. 
 [EW20531]
- 
        At medium optimization level (or higher) for Cortex-M3, compilation of certain combinations of the constant 256 and the question mark operator ( a?b:c) could earlier result in an internal error with the message "illegal state". This has been corrected.
 [EW20537]
- 
        Variables of small type (for example char) could earlier be incorrectly hoisted as a loop counter even though it might wrap. This has been corrected.
 [EW20563]
- 
        A doloop copying consecutive shorts, integers, or long longs have now a correct byte count when translated into a memcpy call.
 [EW20570]
- 
        Return value temporaries created for functions that use a return value pointer did not get marked as having had their address taken. This has been corrected. 
 [EW20572]
- 
        In some cases the code could be optimized incorrectly if pointers of different types were used to access the same memory address. This has been corrected. 
 [EW20581]
- 
        Certain operations (typically bit-wise) involving template static data members of integer type could cause an internal error when compiling template code. This has been corrected. 
 [EW20608]
- 
        A loop could in some cases be incorrectly optimized if it updated a global variable preceded by an indirect store of the same type as the global variable. 
 [EW20627]
- 
        The compiler no longer tries to put CPSIE/CPSIDin an IT-block.
 [EW20652]
- 
        The min and max templates should now be optimized correctly after function inlining. 
 [EW20654]
- 
        The compiler no longer crashes after issuing the error Pe020. 
 [EW20684]
- 
        The intrinsic function __set_CPSR() generated the wrong assembler instruction. This has been corrected. 
 [EWARM-268]
V5.20 2008-06-24
New features- 
        Support for vector floating point (VFP) coprocessors. 
- 
        The compiler no longer removes reads from uninitialized volatile auto variables from the code. 
 [EW19167]
- 
        A thunk with fall through is now padded properly whenever it is needed. 
 [EW19481]
- 
        Source lines after a #linedirective are now included in compiler list files.
 [EW19654]
- 
        The compiler can now handle segment/section names that are the same as assembler instruction names, register names, etc. 
 [EW19674]
- 
        Out-of-line definitions of member functions of a template class are now made properly tentative. 
 [EW19678]
- 
        Declaring a class-specific two-operand operator deletein a class template no longer causes the compiler to crash.
 [EW19707]
- 
        The compiler no longer crashes after emitting an error indicating an extraneous typenamekeyword in a template.
 [EW19796]
- 
        MISRA C rule 23 no longer gives an error for non code symbols. 
 [EW19802]
- 
        Realloc no longer leaves the heap in a broken state after a call that tries to allocate more memory than there is in the heap. 
 [EW19803]
- 
        The compiler no longer crashes when generating DWARF debug information for a class-external typedefof a class-scopedenumtype with more than 9 constants.
 [EW19820]
- 
        When performing memcpyin Cortex-M3 and the source and destination pointers have different alignments, the last 16 bytes are now copied also in cases where the size is:
 size = 32 + ((4 -(DstPtr & 3)) & 3) + (y * 16); // y = 0, 1, 2 e.t.c.[EW19837]
 
- 
        Instruction scheduling will no longer lift pop of LR over a function/library call. 
 [EW19872]
- 
        A call to memmovewith aligned parameters is no longer incorrectly transformed into__aeabi_memcpy4instead of__aeabi_memmove4.
 [EW19878]
- 
        Masking a long longvalue now works.
 [EW19908]
- 
        A function call, where one parameter is a pointer to a signed integral type that is cast to a pointer to the unsigned type of the same size (or vice versa), no longer causes an internal error if the function call is inlined. 
 [EW19933]
- 
        Loops with an unsigned loop variable, going from 0 to 1, will no longer be optimized incorrectly. 
 [EW19973]
- 
        Constant tables layout generation for Thumb2 code has been adjusted. 
 [EW19984]
- 
        In some rare cases structure assignments, where the source was a indirection of a pre- or post-incremented pointer, could be optimized incorrectly. This has been corrected. 
 [EW20071]
- 
        Debug information for variables in high registers ( r8-r14) in Thumb2 code has been improved.
 [EW20098]
 [EW20100]
- 
        Clustering now handles segment/section-located initialized variables. 
 [EW20149]
- 
        In some rare cases an optimization that temporarily hoisted a memory cell (i.e. a global variable or a structure member) to a register did not transform the code correctly and one or more uses could still refer to the memory cell. This has been corrected. 
 [EW20150]
- 
        Fall through from an arm function to a thumb function is no longer generated. 
 [EW20164]
- 
        Invalid instructions no longer generate internal errors. 
 [EW20199]
- 
        Tag_ABI_enum_sizenow reflects the real size ofenumused.
 [EW20203]
V5.11 2007-12-11
New features- Support for Cortex-M1 and Cortex-M3.
- 
        If the code generator failed to place a small object of aggregate type in registers, it could fail also when it tried to place the object on the stack instead. This happened if the alignment of the object did not match the size of the aggregate members, resulting in the wrong offsets being used for all members except those placed on alignment boundaries. 
 [EW19478]
- 
        A 32-bit mask operation with all except the highest bit together with a test on the highest bit of the same variable could generate incorrect code in Thumb mode. 
 [EW19480]
- 
        The section ".textrw" can now be renamed. 
 [EW19672]
- 
        The compiler can now handle segments/sections with names that are identical to names of assembler instructions, registers, etc. 
 [EW19674]
- 
        Out-of-line definitions of member functions of a template class were not made properly tentative, resulting in erroneous 'duplicate definition' errors when linking. This has been corrected. 
 [EW19678]
- 
        Declaring a class-specific two-operand operator delete in a class template no longer causes the compiler to crash. 
 [EW19707]
- 
        Bad syntax in function declarations no longer generate internal errors. 
 [EW19718]
- 
        Doubles are now rounded correctly. 
 [EW20026]
V5.10 2007-06-12
New features- Object files are now produced in the ELF/DWARF format.
- Support for AEABI, which means interperability with other ARM EABI compliant tools.
- 
    	  The compiler now produces an error when an initializer for a static variable 
	      contains the address of a bitfield member.
 [EW17962]
- 
    	  A function-like macro, named as a predefined IAR attribute name, no longer 
	      makes the compiler end erroneously.
 [EW18386]
- 
    	  In rare cases, only the high part of a 64-bit variable was loaded.
 [EW18735]
- 
    	  NOP instructions, inserted with the intrinsic function __no_operation()was scheduled causing them not to appear at the desired places in the code.
 [EW18767]
- 
        The header file MtxWrapper.hnow works from C++.
 [EW18769]
- 
    	  Loops containing array accesses with index expressions ofchartype could earlier in some cases be optimized incorrectly.
 [EW18815,EW18963]
- 
    	  Inconsistencies between several declarations or between declaration and definition 
	      of the same function now give proper diagnostics.
 [EW18818]
- 
    	  The header file Dlib_Product.his now compilable with MISRA C.
 [EW18843]
- 
    	  Interweaved stores with zero and reads from the same structure could earlier be done in 
        incorrect order.
 [EW18845]
- 
	      Wrong code was generated when passing an unaligned struct as parameter in big endian mode.
 [EW18900]
- 
	      swprintfandvswprintfnow correctly handle the ending\0.
 [EW18948]
- 
	      In some rare cases, common subexpressions involving a struct pointer (p->x) was incorrectly optimized if the expression was preceded by an equality test between an other member in the same structure and a constant (p->y == 0).
 [EW19015]
- 
        Functions with __irqand__fiqnow save the vfp status register when compiling for vfp.
 [EW19047]
- 
        The compiler no longer generates an erroneous constant for a compound literal that is
        used in a file-scoped initialization.
 [EW19076]
- 
        swprintfnow handles large strings correctly.
 [EW19105]
- 
        Large functions could give the following internal error:
        Internal Error: [CoreUtil/General]: Jump distance to far for B.
 [EW19179]
- 
        Clustering could cause zero initialized data to occupy ROM space,
        instead of using zero initialization.
 [EW19232]
- 
        The!operator on a byte in acharbuffer (example:return !buf[0];) could earlier cause the internal error:
 Const_Folding - Internal error Unequal types for operator !=
 Internal Error: [CoreUtil/General]: Const_Folding - Internal error
 [EW19337]
V4.41A 2006-12-08
Program corrections- 
            The compiler generated misleading errors for unevaluated parts of constant
            expressions in some circumstances, for 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 containing 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.
 [EW18140]
- 
            In Thumb-mode a tail-call could incorrectly be optimized to jump even when the jump
            distance was just out of reach.
 [EW18151]
- 
            A stack-backtrace information problem with __irqand__fiqfunctions has been corrected.
 [EW18152]
- 
            Inverting a long longvariable could earlier generate an internal error.
 [EW18157]
-          
            Instruction scheduling could earlier incorrectly lose some debug information for inlined functions.
 [EW18180]
- 
            A function containing a structure assignment inlined in a loop body could in some 
            rare cases cause an internal error.
 [EW18182]
-  
            The optimizer could incorrectly remove CMPinstructions if the preceding arguments looked like constants.
 [EW18231]
- 
            When a constant table was placed immediately after a switch table, 
            a dangling (duplicate) label might be left which caused the backtrace 
            analysis to abort the compilation with the following error message
Internal error: [CoreUtil/General]: BtThreadAnalyzer: No direct arc from node to successor [EW18259]
- 
            If the compiler found several stores with zero to consecutive memory locations 
            the last store could be done with wrong size.
 [EW18273]
- 
            The compiler did not handle large functions properly in thumb mode.
 [EW18276]
- 
            The <vector>header no longer relies on the undefined symbol TRUE
 [EW18284]
- 
            Branch chaining optimization could incorrectly chain a BNEinstruction via aBHIinstruction. [EW18312]
- 
             Variables declared both staticandvolatilewere incorrectly not treated as such at all times.
 [EW18316]
- 
              For a structwithshortmembers, the members could incorrectly be written as a 32-bit entity when theshortmember was kept in register. This could also lead to adjacent members being overwritten.
 [EW18320]
- 
             In some rare cases the intrinsic __no_operation()function could give an internal error message.
 [EW18396]
- 
             Bitfield assignments should now work correctly, even when the function call on the right-hand
             side of the assignment modifies other bitfields in the word.
 [EW18460]
- 
              In some rare cases, a series of assignments could be optimized incorrectly, for example assignments like:
x = ...; y = x; x = !z; ... use(y); [EW18540]
- 
            Using #pragma optimizeto lower optimization level for a function no longer affect optimization of static accesses in other functions.
 [EW18582]
- 
            An optimization can lift a global variable to a register in a code region.
            In some rare cases the register was not written back to the variable on all paths from the region.
 [EW18814]
V4.40A 2006-06-03
Program corrections- 
            In some rare cases, the optimizer incorrectly transformed a foror awhileloop to adoloop if: the loop test compared the loop counter to a variable (V) that was invariant in the loop, and the loop was preceded by an if-else-if-statement where the else-if-test testedVagainst a constant value.
 [EW17723]
- 
            High optimization could, in some rare cases, incorrectly hoist a common 
            subexpression (1) across the initialization of another common subexpression (2) 
            where (2) was the value of a global pointer variable and (2) appeared as a 
            subexpression in (1).
 [EW17754]
- 
            Saturate idiom was recognized even at low or no optimization making the code 
            harder to debug.
 [EW17802]
- 
            An ARM-mode peephole optimization could optimize a MUL + ADD to MLA even thou 
            the ADD had a shifted operand.
 [EW17833]
- 
            Functions with inline assembler with labels could incorrectly be inlined.
 [EW17862]
- 
            Incorrect code could in some cases be generated in thumb mode for saturate 
            idiom.
 [EW17868]
- 
            Inlining of functions where a pointer parameter was declared volatile could in 
            some case result in incorrect code.
 [EW17902]
- 
            The result of the instruction scheduling could in some cases differ between 
            compilations with same input.
 [EW17919]
- 
            Functions that dereferenced a pointer after testing if it was NULL could be optimized 
            incorrectly.
 [EW18038]
- 
            Loops that added invariant expression to an indirection of an invariant pointer and the loop 
            index variable (p[i] += 4711) could in some cases be optimized incorrectly.
 [EW18089]
- 
            Unaligned store of zero could give internal error if neighbored with another zero store.
            char charr[100]; *(int*)(&charr[1]) = 0; charr[5] = 0;Note that this kind of code probably will not execute correctly, since most ARM architectures do not support unaligned accesses.
 [EW18124]
- Support for the Cortex-M series has been added.
- Output from the compiler is now in unified assembler syntax.
V4.31A 2006-02-03
Program corrections- 
        Invariant assignments could in some cases incorrectly be hoisted out of fororwhileloops, if the loop test contained an||operator.
 [EW16986]
- 
        High optimization could in some cases generate incorrect code for nested loops 
        if the inner loop was not executed for every iteration of the outer loop.
 [EW17010, EW17064]
- 
        The compiler could in some rare cases loop if the outcome of the condition in a 
        conditional (? :) expression could be determined by assignments in the preceding basic blocks.
 [EW17026]
- 
        Nested irq functions did not return properly.
 [EW17032, EW17033, EW17038]
- 
        A charorshortloop counter initialized with a function call could in some cases result in an internal error.
 [EW17039, 17179]
- 
        Assignments to an auto array could incorrectly be removed as dead code if the 
        only use of the array, besides assignments to it, was to assign the array 
        address to a global pointer.
 [EW17041]
- 
        Incorrect interpretation of the Zflag when analyzing aCMNinstruction could lead to incorrect optimizations.
 [EW17065]
- 
        Accessing a data member of a base class of a class object returned by value 
        from a function call no longer results in an internal error.
 Example:fun().x, wherexis a data member of a base class of the type returned byfun().
 [EW17085]
- 
        Optimization of a function tail call into a branch instruction in a thumb 
        function that takes stack parameters generated wrong stack offset to the stack 
        parameters.
 [EW17117]
- 
        Delayed stack-cleaning in combination with stack access and a conditional (? :) expression could generate wrong stack offset.
 [EW17127]
- 
        Loops where the loop counter was a short intorcharcould earlier result in incorrect code if the loop increment was negative and high speed optimization was used (-s9).
 [EW17129, 17164]
- 
        When constructing a vector of POD data (data with no constructors) with an 
        initial non-zero size, the elements are now correctly zero-initialized. For 
        example:
 vector<int> v(3);vshould in this example contain 3 integers, each initialized to zero. Previously the integers were incorrectly left uninitialized.
 [EW17160]
- 
        Code with both shifting and division by a constant value could in some rare 
        cases generate internal error.
 [EW17162]
- 
        Loops where the trip count was constant and the final statement was a switchexpression could in some cases cause an internal error when high optimization was used.
 [EW17181]
- 
        Incorrect code could be generated for small loops with descending access 
        patterns. For example:
 for (i = 0 ; i < n; ++i) a[100 - i] = ...;orfor (i = 0 ; i < n; ++i) *(p-- + 17)= ...;[EW17184]
- 
        The MISRA C rule 113 states that members of a structure or union shall only be 
        accessed via their name. The compiler now diagnoses a violation of this rule 
        correctly when a pointer to an element of a member array is created. For 
        example:
 struct { int a; int b[2]; } x; x.a; /* Was diagnosed */ x.b[0]; /* Was not diagnosed */[EW17186]
- 
        An __swideclared function pointer now correctly gives an error message.
 [EW17329]
- 
        A register transfer instruction were in some cases optimized away due to 
        incorrect optimizer analysis of sign extend operations.
 [EW17330]
- 
        Incorrect code was generated for assignments of instances of vector<>in two cases:
 1. The assignment of a vector where the elements could use bitwise copy and where the destination vector was smaller than the source vector but had a capacity that was large enough.
 2. The assignment of a vector where the elements needed copying or construction using member functions but did not need destruction, where the destination vector was larger than the source vector.
 These assignments now work correctly.
 [EW17413]
- 
        R8_fiq-R12_fiqwas unnecessarily saved when entering an fiq exception.
 [EW17453]
- 
        The internal error: [Ect]: Optimizehas been corrected.
 [EW17461]
- 
        An error message is now given if the --segmentoption is used more than once with the same segment specifier.
 [EW17463]
- 
        On high optimization, array initializations and assignments to array members 
        could be incorrectly removed as dead code if the only explicit use of the array 
        was to assign its address to a member in a packed struct.
 [EW17466]
- 
        A problem in the instruction scheduling optimizer has been corrected. A popinstruction to restore callee saved registers could be hoisted over an instruction that defined one of theses registers.
 [EW17495]
- 
        When compiling for interwork, a redundant mode change entry will be inserted in 
        front of a generated function. This function may save information about code 
        size if the function is called from code with different mode (arm/thumb). In 
        some cases the compiler missed to generate this mode change entry. The 
        generated code is still correct but can give different code size between 
        compilations.
 [EW17603]
- 
        The command-line option --no_path_in_file_macroshas been added. It removes the path leaving only the filename for the symbols__FILE__and__BASE_FILE__.
V4.30A 2005-06-23
Program corrections- 
          The compilation time is now reasonable when the source code
          contains hundreds of global variables and is compiled
          with high optimization level.
 [EW14199]
- 
        Warning Pa084 ("pointless integer comparison with out of range value") will no 
        longer be issued erroneously in cases where a relational operator is used with 
        a template non-type parameter of integer type.
 [EW16367]
- 
        Some float NaN patterns were not correctly converted to double.
 [EW16373]
- 
        Using compound literals, a C99 feature, could result in an internal error in 
        the compiler.
 [EW16412]
- 
        Inline assembler code with illegal instructions like MOV R0,@R1could generate an internal error
 [EW16414]
- 
        An inline-assembler statement containing nothing but a newline character could 
        cause an internal error in the compiler. Example: asm("\n");
 [EW16415]
- 
        A label placed on the first line of a multi-line inline-assembler statement 
        could cause errors.
 Example:asm("loop:\n" " bra loop");[EW16417]
- 
        Loops with multiple assignments to an auto variable could result in incorrect 
        code, when the loop also contained partial accesses (with a non-zero offset) to 
        the auto variable.
        void ByteSwap128(short *addr) { int i; short tmp; char *dst, *src = (char *)&tmp; for (i = 0; i < 64; ++i) { tmp = *addr; dst = (char *)addr++; dst[0] = src[1]; /* points to (char *)&tmp + 1*/ dst[1] = src[0]; tmp = *addr; dst = (char *)addr++; dst[0] = src[1]; dst[1] = src[0]; } }[EW16419]
- 
        The compiler now generates the same alignment for the following two 
        definitions:
 unsigned char a [6] = {0,0,0,0,0,0};
 unsigned char b [] = {0,0,0,0,0,0};
 [EW16430]
- 
        Loops with a non-constant trip count (number of iterations in the loop) could 
        be uncorrectly unrolled.
 [EW16439]
- 
        Common subexpression elimination no longer hoists expressions that incorrectly 
        can cause an exception, unless the expression is guaranteed to be executed in 
        all successors.
 [EW16443]
- 
        Fixed a problem were iswprint erroneously returned true for the characters 
        carriage return and newline.
 [EW16465]
- 
        Branch-chaining optimization, which is performed at the highest size 
        optimization level, could incorrectly chain a BCSinstruction via aBHIinstruction. This could cause a branch to go the wrong way at runtime depending on the status of the Z-flag.
 [EW16481]
- 
        An expression containing the new operator could generate a reference to the 
        wrong constructor when an optimization level of 6 or higher was used, at least 
        one of the parameters to the constructor was an object passed by copy 
        construction, and the constructor definition was not visible in the same 
        compilation unit as the expression containing the new operator.
 Example:struct X { X(X const &); ... }; struct Y { Y(X); ... }; Y * mkY(int a) { return new Y(a); }If the function mkY was not in the same file as the definition of Y::Y(X), a reference was created to Y::new Y(X *) instead of to Y::new Y(X).
 [EW16482]
- 
        Calculating remainder by a constant could give the wrong result at the highest 
        speed optimization level.
 [EW16487]
- 
        Overlapping stores with zero could caused an exception in the compiler at high 
        optimizations. The compiler analyzes stores with zero to memory and optimizes 
        them. If there were instructions that wrote to overlapping memory locations, 
        the compiler could terminate with the following internal error:
 Internal error: [Ect]: Any exception Fatal error detected, aborting. Internal error: [PostOptimize]: Any exception Fatal error detected, aborting.[EW16489,EW16491]
- 
        Optimizer inlining failed to recognize the #pragma location directive, leading 
        to located code being placed in the wrong segment.
 [EW16529]
- 
        The compiler could generate incorrect code if:
        - A function (f) assigned a variable (p) to point to an object (o) and returned the variable p,
- the function result was assigned to a variable (q) of the same type as p,
- the object o was modified before an access to o through q
- and the function call to f was inlined by the optimizer.
 
- 
        An optimization that tries to hold a global variable in a register during 
        several modifications of the global variable could in some cases cause 
        incorrect code.
 [EW16547]
- 
        In some cases, a loop with an upper bound that was a signed non-trivial 
        expression divided by a power of two could result in incorrect code.
 [EW16550]
- 
        Complex ?:sequences could cause an internal error at the high optimization level.
 [EW16552]
- 
        When compiling EC++, constant variables initialized with simple floating point 
        expressions were put in RAM memory instead of ROM memory.
 [EW16587]
- 
        Corrected an internal error that could occur when an assignment to an auto 
        structure contained a reference to a member in itself or another auto 
        structure.
        struct X x, y, *array; x = array[x.m]; [EW16606,EW16608,EW16627,EW17177]
- 
        A Thumb MOVimmediate to low register could be hoisted in between aCMP-BCC/BCSsequence, which destroyed the effect of theCMPinstruction.
 [EW16611]
- 
        In some rare cases, values were not written to memory before a function call.
 [EW16620]
- 
        Code that implements a saturate operation (keep a value inside a range such as 
        -128 to 127) could produce incorrect code in both Thumb and Arm mode.
 [EW16626,EW16670]
- 
        At the high optimization level 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 zero.
 [EW16646]
- 
        An internal error in constant table generation for functions that end with a 
        fall through to the common exit sequence has been corrected.
 [EW16657]
- 
        Incorrect code could be produced when a "Rn <shift> Rm" operand is spilled to other registers and there is an overlap between one of the original registers and the new destination. The error occurred because the operand was not properly reconstructed to reflect the new registers that the values were moved to.
 [EW16671]
- 
        Optimizer inlining failed to recognize __ramfunc, leading to that code meant to be placed in RAM could end up in ROM.
 [EW16698]
- 
        If both statements in an if else statement are identical (after removal of dead 
        code) an optimization that merges the two statements could in some cases also 
        remove side effects (for example calls or volatile accesses) in the redundant 
        condition.
 [EW16735]
- 
        Incorrect code could be generated when the initial value for a signed loop 
        counter was computed with an & expression where both operands where 
        non-constant expressions.
 [EW16757]
- 
        Two STRBwith zero to offset 256 and 257 could be compiled into a singleSTRHwhich then had its offset truncated to 0.
 [EW16885]
- 
        Coprocessor instructions MCR and MRC are no longer moved around by the 
        instruction scheduler. They previously were allowed to be move past a volatile 
        side effect.
 [EW16886]
- 
        If a loop with a variable upper limit was preceded by a modification of the 
        upper limit and a test of the upper limit being larger than the lower limit of 
        the loop, the optimizer could incorrectly assume the loop body should always be 
        entered.
        
 if (u > 0) { --u; for (i = 0; i < u; ++i) { ... } }[EW16887]
- 
        Including an I/O definition header and referencing more than one SFR from C++ 
        code will no longer result in incorrect "more than one definition for 
        struct/union type" warnings when linking.
 [EW16957]
- 
        Unrolling of loop with non-constant trip count could cause internal error in 
        the optimizer.
 [EW17006]
- Support for ARM11 and V6 has been added.
- The execution speed of the floating point library has been significantly improved.
- Code size and speed performance have been improved for both ARM and Thumb.
- It is now possible to declare variables in the initialization clause of a for statement, but only in extended language mode. This behavior is according to the C99 and the C++ standards.
- 
        You can now compile several source files in one compilation by specifying the 
        command line option --mfc. The advantage of multi-file compilation is that it 
        gives the interprocedural optimizations a larger set of functions to work on. 
        If you also specify the command line option --discard_unused_publics, the 
        optimization will be further improved because the compiler will assume that 
        there are no references to any symbol from the outside in the compilation, i.e. 
        the compilation unit is the whole application apart from the library.
 Use the --mfc option with caution, because it is experimental in this version of the compiler.
- 
        Some more C99 functionality has been added to the IAR DLIB Library:
 - Ctype.h defines isblank as an added function.
- Inttypes.h has been added. Note that only the conversions are included, not the functions.
- 
            Math.h defines the following additions:
 Macros - HUGE_VALF, HUGE_VALL, INFINITY, NAN, FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, FP_ZERO, MATH_ERRNO, MATH_ERREXCEPT, math_errhandling.
 Typedefs - float_t, double_t.
 Macro functions - fpclassify, signbit, isfinite, isinf, isnan, isnormal, isgreater, isless, islessequal, islessgreater, isunordered.
 
- Stdlib.h defines llabs, lldiv, strtoll, strtoull, atoll, strtof, and strtold as added functions.
- Wchar.h defines vfwscanf, vswscanf, vwscanf, wcstof, and wcstolb as added functions.
- Wctype.h defines iswblank as an added function.
 
V4.20A 2005-01-10
- 
      Program corrections
- 
          Using #pragma vectoron an interrupt function did not update the exception vector table.
 [EW14086]
- 
          A function definition at a line number greater than 65535 could cause an 
          internal error, due to an unused line number field in an object file record 
          that overflowed.
 [EW15542]
- 
          Call to an __irqor__fiqfunction could generate an internal error.
 [EW15561]
- 
          __ramfuncfunctions shared relay functions with non__ramfuncfunctions in the same module. If they were placed far from each other that could generate a link error.
 [EW15562]
- 
          The scheduler failed to recognize overlapping load and store operations if they 
          were of different size.
 [EW15579, EW15656]
- 
          A volatile load directly following a store to the exact same location could 
          reuse the stored value instead of loading it again.
 [EW15582, EW15657, EW15663]
- 
          A declaration of a block local variable with no initialization, immediately 
          followed by a label, resulted in incorrect code in some cases.
 [EW15594]
- 
          In some cases auto-variables of union type were optimized incorrectly. 
          Assignments to a member (m) were incorrectly removed if the union definition 
          contained a declaration of another member, of equal or larger size, below the 
          declaration of m.
 [EW15595]
- 
          The scheduler could generate an internal error for a large basic block without 
          any statement info.
 [EW15596]
- 
          If a function had multiple return statements and all returns were preceded by 
          an assignment to the same global variable (or an indirect assignment using the 
          same pointer), the return value could be overwritten by a temporary value.
 [EW15600]
- 
          Some caller-saved registers were not saved when calling library routines for 
          floating point subtraction and division.
 [EW15601]
- 
          Fall through to a large 'common exit sequence' with several constant references 
          could generate constant entries out of bounds.
 [EW15613]
- 
          ANDwith a constant that was converted toBICon a variable smaller than 32 bits could leave garbage in the higher bits of the register.
 [EW15621]
- 
          In some cases auto-variables of structure type caused an internal error if the 
          structure had a member of union type.
 [EW15622]
- 
          A register parameter could in rare circumstances be allocated in the same 
          register (or overlapping register) as another local variable.
 [EW15623]
- 
          Hoisting of loop-invariant code could in some rare cases generate incorrect 
          code.
 [EW15624]
- 
          Code optimized to a conditional tail jump could generate an internal error.
 [EW15625]
- 
          A basic block could in some cases be flattened even if it had multiple 
          predecessors with different flags set.
 [EW15627, EW15768]
- 
          FLDS,FLDD,FSTSandFSTDcan now have relocatable offset. This is needed when accessing constants from vfp code.
 [EW15641]
- 
          Constant entries could in some cases, especially large long longswitches, be placed among the switch data. This could lead to random jumps anywhere in memory.
 [EW15643,EW15660,EW15661,EW15665]
- 
          Invariant definitions were in some cases hoisted even if it defined alive 
          non-invariant resources or used a non-invariant resource.
 [EW15646]
- 
          Offset check for constants placed in another segment part was too pessimistic. 
          This could lead to internal error.
 [EW15653,EW15654]
- 
          In some rare cases the compiler performed incorrect optimizations (for example 
          constant propagation or common subexpression elimination) of accesses through 
          pointers. The effects were noticeable when the same data object was accessed 
          through different pointers. The problem was unlikely to occur in non-trivial 
          functions.
 [EW15655]
- 
          long longswitch in thumb mode could generate unaligned accesses.
 [EW15659]
- 
          In some cases the compiler tried to flatten a basic block ending with a table 
          switch. This generated broken code.
 [EW15664]
- 
          In some cases union accesses were optimized incorrectly. The union accesses 
          could only have two sizes and one of the sizes must be the whole union. 
          Accesses of the two differing sizes must be interleaved so the contents of the 
          union was read with a different size than the value stored in the union.
 [EW15681]
- 
          The intrinsic __no_operation()could be optimized away in Arm mode.
 [EW15690]
- 
          When a volatile-declared variable was used in the index expression of a 
          volatile-declared array expression, the compiler issued an incorrect warning 
          about undefined order of volatile accesses.
 [EW15710]
- 
          The #pragma vector was broken in several ways.
 1. The segment part was generated as noroot causing the linker to remove it.
 2. Multiple vector numbers was not recognized.
 3. The vector number was scaled wrongly.
 [EW15781]
- 
          When typedefs were involved in an integer comparison, the compiler sometimes 
          incorrectly issued the warning Pa084 (pointless integer comparison with out of 
          range value) for cases where such a warning was inappropriate.
 [EW15793]
- 
          Swi vector for declared only functions was sometimes treated as 0.
 [EW15862]
- 
          A thumb peephole pattern which propagates an ADDinstruction beyond aLDR/STRinstruction by modifying the addressing mode of theLDR/STRinstruction did not take care of all situations properly with respect to flags being alive after the instruction.
 [EW15898, EW16191]
- 
          The compiler could generate wrong debug information for local variables causing 
          them to be shown as unavailable in the debugger watch window.
 [EW15948]
- 
          Complex expressions containing a signed division with a constant denominator 
          could in some cases cause an internal error.
 [EW16000]
- 
          Evaluation of expressions with the %=operator now follows the rules for integral promotion.
 [EW16001]
- 
          The internal header file xlocale.hdid not work properly when the current locale was the C locale (which it typically is) and the symbol C was defined as a preprocessor macro.
 [EW15602]
- 
          The use of a variable (x) could incorrectly be eliminated from an expression, 
          if 1. the expression contained both a use and a defining use of x and 2. the 
          expression contained a use of another variable (b) that was the single use of 
          it 3. no defining use of x occured before b's defining use
          void use(int); int broken(void) { int x; /* x uninitialized */ int a = 1; int b = 2; /* b's definition */ x = a; /* this defining use of x is overlooked */ use(x); x = b + x; /* use and def of x, use of b */ use(x); return x; }[EW16002]
- 
          The compiler now attempts to warn about undefined behavior in some situations 
          involving sequencing or multiple modifications with no intervening sequence 
          point. If this warning involved data accessed through the implicit thispointer of a C++ member function, an internal error resulted.
 [EW16021]
- 
          The scheduler could rearrange code including a constant load to VFP register 
          even when conflicts would appear.
 [EW16051]
- 
          An initialized autoarray inside a loop no longer causes an internal error.
 [EW16052]
- 
          Relay function to div/modtrashed R2 in thumb mode. Such relay functions is needed when the distance between the caller and the callee is more than 4 Mbytes.
 [EW16061]
- 
          A problem where using the preprocessing operator definecould cause an internal error has been corrected.
 [EW16076]
- 
          Register allocation of VFP registers could differ between compilations of a 
          specific source code depending on Windows memory allocation. The code produced 
          was correct, but not necessarily identical.
 [EW16083]
- 
          Long functions can make use of spring board jumping which utilize existing 
          jumps to avoid generating a long branch, by forming branch chains. In one rare 
          case a conditional branch immediately preceeding the destination label could 
          incorrectly be incorporated in such sequence (its destination points elsewhere, 
          but it has fall-through flow to the target label).
 [EW16097]
- 
          Defining a C preprocessor macro with the same name as any directory component 
          of the library configuration file path would change that component giving the 
          wrong path.
 [EW16220]
- 
          long longoperations such asadd,subtract,negatecould be incorrectly made if the low part of the result overlapped with the upper part of one of the operands. This happened in some rare situations when the register pressure was high.
 [EW16331]
- 
          8-bytes stack alignment was not always preserved.
 [EW16332]
- 
          Complex pointer to data member access could generate internal error with bad 
          data alignment.
 [EW16370]
- 
          The compiler could terminate with
 Internal Error: [CoreUtil/General]: Const_Folding
 when doing a cast on pointer arithmetics.
 [EW16898]
- 
          The common subexpression elimination optimization could could give different (but correct)
          output depending on compilation environment, producing slightly different (but correct)
          code between compilations.
 [EW17918]
- 
        A new object attribute, __noreturnhas been added. The attribute can be used on functions to inform the compiler that the function will not return. The compiler can then generate more efficient code. Examples of functions that do not return areabort()andexit().
- 
        To determine the configuration file for DLIB from the command line, use the 
        compiler option --dlib_config config_file. The old variant, using-D_DLIB_CONFIG_FILE=config_file, will still work but can interfere with other preprocessor defines.
- Support for compound literals has been added to the C language.
- 
        New compiler command line option --preinclude include_file.
- 
        The inline assembler operator asm()now supports multiple instructions and local labels. Example
 asm("Loop: MOV R0,#10 \n" " ADD R3,R3,R2 \n" " SUB R0,r0,#1 \n" " BNE Loop");Note that the instruction separator is'\n'and that the definition and the reference of a local label do not necessarily need to be in oneasm().
V4.11A 2004-06-10
- 
        The following C99 features can now be used in the C language if language 
        extensions (-e) are enabled:
        - 
            The inlinekeyword. It works as the C++ inline keyword (and the#pragma inlinedeclaration).
- Mixing declarations and statements within the same scope.
- Having a declaration in the initialization expression of a for-loop.
 
- 
            The 
- 
        The standard library fopen()function incorrectly worked and returned a valid file pointer, even when not linking the application with the debug information without I/O emulation modules, available by choosing Project Options and selecting the Linker category.
 [EW13922]
- 
        In rare cases at high optimization levels, the optimizer data flow analysis 
        could fail with an internal error.
 [EW15026]
- 
        The namespace scope of extern "C" functions was incorrectly included in their 
        linker visible names, which sometimes could lead to incorrect Undefined 
        External errors when linking.
 [EW15088]
- 
        Instruction scheduling could in some cases change the order of two volatile 
        read accesses.
 [EW15119]
- 
        In some cases an array element reference could be optimized incorrectly if the 
        address was computed in two separate expressions and both contained the loop 
        counter. For example.
        int a[100][100]; int foo() { int i; for (i = 0; i < 10; ++i) { int *p = &a[i][0]; /* first use of i */ p[i * 2] = 4711; /* second use of i */ } }[EW15123]
- 
        If all paths to a switch statement with a single variable as a switch 
        expression contained assignments to the variable, it could in some rare cases 
        cause the compiler to loop when all the jumps to the switch were redirected to 
        their destination into the switch body.
 [EW15131]
- 
        Functions declared __swiand with calls to other functions could generate an internal error.
 [EW15327]
- 
        The va_start1()intrinsic function incorrectly gave a warning when the optionrequire_prototypeswas used.
 [EW15328]
- 
        Switch on character expression with all case values between 0x80 and 0xFF could 
        generate incorrect code.
 [EW15349]
- 
        Too agressive optimization could incorrectly casuse a needed ANDinstruction to be removed.
 [EW15396]
- 
        The treatment of the #pragma segmentdirective has been changed to allow multiple equivalent declarations of the same segment.
 [EW15413]
- 
        A switch statement with case values in a range greater than 255 could generate 
        an internal error.
 [EW15462]
- 
        The compiler printed diagnostic text contained the obsolete segment types HUGEDATAandHUGECONSTinstead ofDATAandCONST.
 [EW15464]
- 
        Library call from located functions could incorrectly cause reference to 
        undefined symbol.
 [EW15465]
- 
        A function with a parameter of type pointer to class could sometimes get an 
        incorrect name in the object file, resulting in an 'undefined external' error 
        when linking. For this to happen, the class must have a user-defined or 
        non-bitwise compiler generated copy constructor, and there must be a definition 
        of another function in the same module returning the class by value. That 
        function must, apart from the pointer to class parameter, be declared with the 
        same parameter types as the first function.
 [EW15466]
- 
        An ARM function compiled for VFP with an integer parameter located in register 
        and later stored on the stack could generate an internal error.
 [EW15469]
- 
        No relay function was generated for calls to __ramfuncfunctions declared in the same module even though the distance was too far for theBLinstruction.
 [EW15485]
- 
        The shift count was not properly zero extended for long longshifts.
 [EW15500]
- 
        If a register was used in a loop only by a single instruction, that register 
        could incorrectly be considered as dead after the refering instruction.
 [EW15612]
V4.10B 2004-03-09
- 
        Two new intrinsic functions are now available in the compiler, __MCR()and__MRC(). They make it possible to access coprocessor registers from C and C++, and not just from assembler language.__MCR()inserts a coprocessor write instruction,MCR, and__MRC()inserts a coprocessor read instruction,MRC. For syntax details, please see the inarm.h header file.
- 
        A new compiler command line option, --separate_cluster_for_initialized_variables, has been added to separate initialized and uninitialized variables, when using variable clustering. The use of this option can make the*_IDsegments smaller at the expense of code size. Variable clustering is disabled altogether by the--no_clusteringcommand line option.
- 
        A new compiler keyword, __nestedis available to allow nested interrupts. The keyword modifies the enter and exit code of an interrupt function to allow interrupts to be enabled and to be served inside the interrupt function without overwriting theSPSRand return address inR14. Nested interrupts are only supported for__irqfunctions. For example:__irq __nested __arm void interrupt_handler(void); 
- 
        Some ISO C99 features have been added. They are available when language 
        extensions are enabled.
        - 
            Support for the bool data type, if the header file stdbool.hhas been included.
- _Pragma support. This operator works as the pragma directive and can be used in macro definitions.
- 
            Variadic macro support. You can now write printf-style macros.
 
- 
            Hexadecimal floating point constants support. This means the ability to exactly 
            specify a floating point constant. The functions strtod(), printf(), and 
            scanf()  recognize the syntax.
 
- 
            The macro definition __func__. If used in a function, it is defined to the name of the function.
- Designated initializers. Using these, you can initialize a specific element in a structure or a specific element in an array.
- 
            Inline functions. The pragma directive inline[=forced]has been added as well.
- 
            long longsupport in the library. For example the functions strtoll(), strtoull() have been added as well as support for them in printf() and scanf().
 
- 
            Support for the bool data type, if the header file 
- 
        The localtimeC++ runtime library function generates negative values for thetm_mdayelement.
 [EW12510]
- 
        The compiler could generate an internal error when performing live-dead 
        analysis on a data pointer that was casted from a function pointer. The problem 
        was present on optimization levels medium (-z6/-s6) and high (-z9/-s9).
 [EW14949]
- 
        No relay is generated in the following code (The compiler does not know how far 
        apart these two functions actually are...)
        #pragma location="CALLEE" __thumb void callee() { volatile int a = 0; } #pragma location="CALLER" __thumb void main() { volatile int a; callee(); a=1; }[EW14973]
- 
        In the following code the relay for the call from caller() to callee() will be 
        'knocked out' by the relay entry to callee.
        #pragma location="CALLEE" __thumb __interwork void callee() { volatile int a = 0; }[EW14975]
- 
        In a member function of a template class or one of its nested classes, a delete 
        expression involving a pointer to one of these classes could cause an internal 
        error when compiling.
 [EW14979]
- 
        When compiling C++ code, the compiler could fail with an internal error when 
        the result of a struct/class/union assignment was used (for instance in a 
        chained assignment expression), the struct/class/union had no user-written 
        assignment operator, and the assignment could be performed as a bitwise 
        assignment.
 [EW14981]
- 
        The body of the following loop was incorrectly treated as invariant.
        struct { int x; int array[10]; } s; void f(void); void g(void); void test() { int i; for(i = 0; i < 8; ++i) { if (s.array[i]) { f(); return; } } g(); }[EW14985]
- 
        When an inline member function was called from an __arm function, instead of 
        calling the member function the object's destructor was called.
 [EW15102]
- 
        When an inline member function is called from an __arm function, instead of 
        calling the member function the object's destructor was called.
 [EW15103]
V4.10A 2004-02-21
- 
        Valid stack backtrace information is now available in the IAR C-SPY Debugger 
        inside the __irqand__fiqinterrupt functions.
 [EW12251]
- 
        Variables initialized to zero, either by explicitly setting them to zero in the 
        code or as default behavior when no value is given, were cleared to zero by cstartup. 
        A very small table entry was used to describe an entire block of memory to be 
        cleared. If such zero-initialized variables are clustered together with 
        variables that have explicit non-zero initializers, they would get explicit 
        zero bytes to be copied by cstartup. If the zero-initialized variable 
        was large (an array, for example), this could result in a waste of read-only 
        memory. There is a new option that can be used to correct the described 
        behavior:
 --separate_cluster_for_initialized_variables
 Separate initialized and uninitialized variables, when using variable clustering.
 [EW12980]
- 
        The stdoutstream is now buffered. Unbuffered stdio could cause slow terminal I/O performance in the debugger.
 [EW13609]
- 
        Assignments of derived class objects to base class variables (also known as 
        "slicing" assignments) where the assignment could be performed by bitwise 
        copying caused an internal error when compiling.
 [EW14094]
- 
        Some syntax errors could cause a subsequent internal error when the --require_prototypesoption was used.
 [EW14107]
- 
        When generating a constructor or destructor for an unnamed structure or class 
        (for example, because one of its members had a constructor or destructor) an 
        internal error occurred.
 [EW14149]
- 
        An internal error was generated for a switch case value which was out of range 
        for the switch type.
 [EW14304]
- 
        The compiler sometimes generated incorrect code when dividing with, and 
        comparing with -1 in a single statement.
 [EW14344]
- 
        In some cases loops with long longloop counters could be optimized incorrectly.
 [EW14345]
- 
        Incorrect code is no longer generated for long longdecrements.
 [EW14347]
- 
        Fix of several problems regarding bitfields in long longbase types.
 [EW14357, EW14361, EW14362, EW14366, EW14378]
- 
        An internal error with the message "Jump distance too far for B" could occur in 
        some rare situations.
 [EW14358]
- 
        Casting between floatand thelong longsignedandunsignedtypes failed in Thumb mode when using the software floating-point runtime library. The library functions handling the casts used a return sequence that was not compatible with the v4 instruction set. Therefore, the Thumb state was not preserved by these casting operations.
 [EW14365]
- 
        Side effects of function calls was not correctly handled for global bit fields.
 [EW14367]
- 
        The intrinsic function __QFlag(), which is declared in inarm.h, is now correctly acknowledged as an intrinsic function by the compiler.
 [EW14405]
- 
        All functions (including, but not limited to, all relay functions) are now 
        KEEP_WITH_NEXT instead of REORDER. This prevents them from being reordered at 
        link time, if packed placement (-P) is used. This is only an issue for 
        applications larger than 4 Mbyte.
 [EW14454]
- 
        Float comparison could result in an internal error at the highest optimization 
        level when using the vector floating-point (VFP) unit.
 [EW14669]
- 
        Compares with 0.0 when generating code for VFP was sometimes done as if the 
        hardware supportes subnurmal-numbers.
 [EW14670]
- 
        Template functions and member functions of class templates that were not inline 
        (implicitly or explicitly) could cause an internal error in the compiler.
 [EW14680]
- 
        The intrinsic function __CLZ()gave an internal error when compiled at optimization levels above 3.
 [EW14723]
- 
        The extra 'new constructor'/'delete destructor' routines generated by the 
        compiler when optimizing for space should be marked as tentative if the class 
        involved is a template class, even if the corresponding constructor/destructor 
        is not tentative. The compiler failed to do this, which could result in 
        multiply defined symbol errors when linking.
 [EW14746]
- 
        In some cases an assignment to a member in a structure variable could be 
        erroneously eliminated, if the member was assigned a variable and that variable 
        was assigned in all basic blocks preceding the basic block containing the 
        structure variable declaration.
 [EW14760]
- 
        Optimization no longer treats ~(x - y)as-(x - y).
 [EW14788]
- 
        Printfformat string characters above 0x7F were not handled correctly.
 [EW14897]
- 
        When trying to avoid unnecessary setting of the vtablepointer in the constructor for abstract classes, if the class has a member variable that is an array of objects requiring construction, the compiler could hit an assertion in the internal file lower_init.c.
 [EW14909]
- 
        When generating a constructor or destructor for an unnamed structure or class 
        (for example, because one of its members had a constructor or destructor) an 
        internal error occurred.
 [EW14911]
- 
        Converting numbers using wcstoul()with more than 9 decimal digits gave the wrong result.
 [EW14921]
- 
        The extra 'new constructor'/'delete destructor' routines generated by the 
        compiler when optimizing for space should be marked as tentative if the class 
        involved is a template class, even if the corresponding constructor/destructor 
        is not tentative. The compiler failed to do this, which could result in 
        multiply defined symbol errors when linking.
 [EW14931]
- 
        A structure that only containes small integral types plus another structure of 
        small integral types generated 32-bit LDR/STR instructions when operating on 
        non-aligned data objects.
 [EW15593]
- 
        In some situations the access to a variable could be hoisted above an 
        assignment to that variable.
 [EW16828]
V3.40C 2003-12-12
- 
        ELF/DWARF debug information for variables located in VFP double registers could 
        not be handled by the linker. A linker internal error was generated.
 [EW14206]
- 
        In some cases expressions containing a negation could cause an internal error 
        if the expression below the negation was an associative and commutative 
        expression with several constants.
 For example certain expressions with succeeding minus signs, as in-(108000000-(temp-108000000)).
 [EW14293, EW14532]
- 
        Missing intrinsic function declarations of __get_CPSR()and__set_CPSR()have been added to the inarm.h header file.
 [EW14300]
- 
        In some cases loops with long longloop counters were optimized incorrectly.
 [EW14345]
- 
        If a function that was compiled as __monitor __thumb __interworkdid not destroy any registers that had to be restored, for example if the function body was empty, an internal error was generated.
 [EW14445]
- 
        Some standard I/O library functions was linked into the application even if not 
        used.
 [EW14465]
- 
        When common sub-expression elimination (CSE) was enabled in the compiler 
        optimizer, some constructs were previously optimized incorrectly. An example of 
        such a statement is:
 k = i + j + k;
 [EW14497]
V3.40B-P1 2003-10-06
- 
        Compiling with VFP enabled in ARM mode, and declaring a function with __thumbin the same translation unit, could cause an internal error at optimization levels above 3.
 [EW14210, EW14211]
- 
        The runtime library routine ??div8_ahas been corrected so that it now makes a full 32-bit sign-extension of the divisor and dividend, as opposed to a 16-bit one, prior to performing the actual division operation. The previous behavior was not a bug according to the C standard, but it could unnecessarily lead to an "undesired" result.
 [EW14239]
- 
        The result from signed 8- and 16-bit divide and modulo operations is now 
        (correctly) sign extended.
 [EW14298]
- 
        Optimizations based on register content tracking did not function correctly for 
        multidimensional arrays. This could result in incorrect optimization of an 
        access to an element in a multidimensional array, if two or more paths through 
        the function could reach the access and at least one of the paths contained an 
        assignment to the same element. Single dimensional arrays could also be 
        affected if they were clustered. This problem only occured on optimization 
        levels above 3.
 [EW14342, EW14354]
- 
        Structures small enough to fit within a register could in some cases be read 
        with incorrect alignment, that is with a single large read instruction instead 
        of several small ones. This resulted in an undefined behavior.
 [EW14353]
- 
        The expression X-(Y*Z)was incorrectly coded asFMSC[S|D]instead ofFNMAC[S|D]when using VFP. Since this type of expressions are present in the sourcecode forsin(),cos(), andcosh(), applications using these library functions were affected.
 [EW14359, EW14373, EW14389]
- 
        VFP function pointers were previously not recognized as the default function 
        type.
 [EW14360]
- 
        Using VFP and casting a floatto anunsigned intorlongcould give the wrong rounding mode depending on the rounding mode set inFPSCR. Previously, theFTOUISinstruction was used, but the rounding mode ofFTOUISdepends onFPSCRand gives the wrong result unless round towards zero is set inFPSCR. Now, theFTOUIZSinstruction is correctly used instead.
 [EW14363]
- 
        Using VFP and casting a doubleto asigned intorlongcould give the wrong rounding mode depending on the rounding mode set inFPSCR. Previously, theFTOSIDinstruction was used, but the rounding mode ofFTOSIDdepends onFPSCRand gives the wrong result unless round towards zero is set inFPSCR. Now, theFTOSIZDinstruction is correctly used instead.
 [EW14364]
V3.40A 2003-07-03
- 
        Compiler assembly output in interwork mode could fail to assemble.
 [EW13604]
- 
        A loop containing a condition, where a loop counter was multiplied with a value 
        greater than 1 and compared to a constant, could, if certain additional 
        conditions were met, be optimized incorrectly due to rounding errors when 
        loop-peeling optimizations were performed. For example:
        int i, res; for (i = 0; i < 3; i++) { if((i * 2) < 1) res = 0; else res = 1; printf("i=[%d]:res=[%d]\n", i, res); }Loop-peeling optimizations are only attempted when there is a maximum of three basic blocks within the loop and the highest optimization level (-z9/-s9) is used.
 [EW13695]
- 
        When using Thumb mode and a long long, or a value whose temporary internal representation waslong long, was part of a struct and located at an offset of 124 (bytes) within the struct, the compiler sometimes tried to generate syntactically illegal code. As a result, an internal error was generated.
 [EW13702]
- 
        The global optimizer could in very special cases lose track of a temporary 
        result.
 [EW13925]
- 
        In some rare cases, the global optimizer could make incorrect assumptions of 
        the contents of a clustered variable, b, inside a loop. Incorrect code was generated in these cases. For this to occur, the loop must reside within an if-else statement, it cannot changebbut must change another variable in the same cluster, andbmust be assigned in the other clause of the if-else statement. For example:int a; int b; void f(void) { if(a < b + 2) { while(a + b <= 0) a++; } else { b = b + 2; } }[EW13936]
- 
        In some cases, inner loops could be optimized incorrectly if the trip count 
        depended on the loop counter in a surrounding loop, the surrounding loop had a 
        trip count of 2, and the loop counter in the surrounding loop counted down.
 [EW13937]
- 
        In some cases, nested loops could be optimized incorrectly if the exit test in 
        the inner loop jumped directly to the test in the outer loop. For example:
        x = ...; while (--x > 0) { y = ...; while (--y > 0) { ... } /* no code from outer loop here */ }[EW13942]
- 
        When SFBorSFEdirectives were used on segments containing tentative segment parts (PUBWEAKsymbols), one such tentative segment part was used in the calculation ofSFB/SFE, and the chosen definition of the segment part was located in a different segment than the tentative one, XLINK could generate the wrong value for theSFB/SFE.
 [EW13972]
- 
        The compiler could produce different object code depending on the execution 
        environment, such as the host operating system used. However, the generated 
        code was correct in all cases.
 [EW14003]
- 
        Signed compare on long longwas previously performed incorrectly. The generated code performed an all-signed compare, when it should have done a signed compare on the high 32-bit word and an unsigned compare on the lower part.
 [EW14020]
- 
        The sign-on message for the --segmentcommand line option has been corrected. The sign-on message is displayed when invoking the compiler from the command line by typing "iccarm" only.
 [EW14044]
- 
        Const objects which are located at an absolute address, and either implicitly 
        initialized to zero or explicitly initialized to any value, were previously 
        incorrectly placed together with located no_init (const and non-const) objects 
        in the HUGE_AN segment. Now, they are correctly placed in the HUGE_AC segment.
 [EW14050]
- 
        In some cases volatile global variables could lose the volatile attribute if 
        they were clustered. Clustering was performed on highoptimization level (-z9/-s9) only. For example:int y; int z; int volatile x; void f(void) { x = y; x = z; }[EW14051]
- 
        All printf formatters, such as %dand%s, gave an incorrect output when the_Printf_smallformatter was used.
 [EW14068]
- 
        The following example previously generated Thumb ADDandSUBinstructions in ARM mode, which resulted in an internal error.char x[8]; void foo(void) { *(int*)&x[1] = 1; }[EW14070]
- 
        An internal error could be generated when compiling Thumb code containing 
        certain forms of 32-bit integer multiplications.
 [EW14093]
- 
        A loop containing a condition, where a scaled loop counter was compared to a 
        constant, could be optimized incorrectly if the test was for (non-)equality and 
        the value was reached during the final iteration through the loop.
 [EW14096]
- 
        Signed long long division with negative numbers gave wrong sign on quotient and 
        remainder.
 [EW14117]
- 
        Long long arithmetic right shift failed if high word was all ones.
 [EW14118]
- 
        Alignment of complex objects like character arrays is now set to 4. The 
        previous alignment of one was not a bug according to ANSI, but could cause code 
        written for other ARM compilers to fail at runtime due to unaligned accesses. 
        As an example, this could happen when casting a character pointer to an int 
        pointer.
 [EW14123]
- 
        Passing a pointer to long long as argument to a function could cause an 
        internal error.
 [EW14126]
- 
        Standard input in C-SPY with library buffered I/O enabled did not work. In 
        addition, redirecting stdin from a file in C-SPY caused an application error.
 If library buffered I/O was disabled, the standard input worked correctly.
 [EW14174]
V3.30B 2003-03-18
- 
        When the compiler generated relay functions to Thumb assembler library 
        routines, for example ??divu32,??div32,??divu16,??div16,??divu8, and??div8, it accidentally destroyed the contents of non-scratch register R11. R11 is seldom used by Thumb code generation, but in ARM functions which call Thumb library code, this problem could surface if relay functions were needed. Now relay functions correctly use scratch register R12 instead.
 [EW10737, EW13614]
- 
        When performing crossjump or hoisting optimizations, which is done on 
        optimization levels -z9/-s9, the compiler incorrectly assumed that all inline assembler routines were identical. This could lead to an overly aggressive use of these optimization techniques, which resulted in incorrect code sequences to be generated.
 [EW13638]
- 
        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.
 [EW13651]
V3.30A 2003-02-18
- 
        va_arg()now works for structs that are not word-aligned.
 [EW10145]
- 
        Formatted I/O functions, like printf, can now handlelong long.
 [EW10898]
- 
        The combined number of variables/functions per file is no longer limited to 
        64k.
 [EW12299]
- 
        Using the same segment name multiple times as an argument to the __sfb()or__sfe()intrinsic functions resulted in an internal error:
 Internal Error: [Front end]: compare_constants: bad address constant kind
 [EW12783]
- 
        In some cases, assignments to elements in arrays with an unspecified size could 
        be removed if the same element was used exactly once later in the same basic 
        block.
 [EW12790]
- 
        A remark that had been converted to a warning could not be suppressed using the --diag_suppresscommand line option.
 [EW12847]
- 
        An internal buffer overflow could occur if a very long file name was used in 
        combination with a very long function name. When this happened, the result 
        could either be no diagnostic message, or one of the following two internal 
        errors:
 Internal error: [write_ABS_UBROF A01]: Illegal tag (P0: 0, P1: 0)
 or
 Internal error: [any]: Unexpected exception
 [EW12851]
- 
        A casted pointer expression could result in an internal error similar to:
 Internal Error: [AsmLine - OgAsm]: Error[43]: Illegal effective address
 ADD R1,#+0x2
 [EW12883, EW12884]
- 
        Peephole optimization of additions, where the first operand was known to be 
        smaller than the type of the addition and the other operand was a negative 
        constant, did not take the effects of propagated carry bits into account. If 
        only a part of the sum was used (for example by shifting or masking the sum) 
        and those bits came from the bits known to be cleared in the first operand, the 
        result was optimized incorrectly.
 [EW12973]
- 
        Incorrect code was generated for a pure 32-bit division when the divisor was a 
        constant with a value of 2^n, and optimization was turned on. The problem was 
        an incorrect mask constant.
 [EW12975]
- 
        If a multiplication of two long longnumbers was made in Thumb mode inside a leaf function (a function that does not call any other functions), the link register was not properly preserved for function return, which resulted in an eternal loop.
 [EW12979]
- 
        If a switch statement contained only case constants that were impossible to 
        reach due to the size of the switch expression type, an internal error occurred 
        when no optimization was used.
 [EW12983]
- 
        Accessing an element of an array in a packed structure type could cause a 
        spurious warning:
 Pa039: use of address of unaligned structure member
 [EW12997]
- 
        In some cases where several structure members were assigned loop invariant 
        values, the optimizer could mistakenly use the value from another member.
 [EW13030]
- 
        The compiler could get into an infinite loop for certain loop constructs at 
        optimization level -z6and above.
 [EW13031, EW13048]
- 
        An assignment from an array element to another in the same array could be 
        optimized away at optimization level 4 and above, if the only use of the array 
        after the assignment was to pass the array pointer itself to another function.
 [EW13068]
- 
        Negating variables of type long long intpreviously generated incorrect code.
 [EW13077]
- 
        At optimization level -z4or higher, the compiler could give an internal error with the message:illegal state
 [EW13160]
- 
        Incorrect code could be produced when the common subexpression and code motion 
        optimizations were turned on (optimization level 7 and above).
 [EW13169]
- 
        Multiplying a variable with itself could result in an unpredictable instruction 
        (operand combination) being generated in Thumb mode.
 [EW13171, EW13362]
- 
        In some cases, the sum of two expressions, where both expressions could be 
        expressed as k*x + m (k and m are constants and x is a loop variable), could be 
        calculated incorrectly.
 [EW13184]
- 
        The compiler could hang on certain code constructs.
 [EW13185]
- 
        There was a problem in auto-variable allocation that could cause two array or 
        struct variables to be allocated to the same space on the stack, even when they 
        were both alive at the same time.
 [EW13186]
- 
        The code generated for a constant shifted by a 2^n scaled value inside a loop 
        was incorrect, when compiled with High speed optimization.
 [EW13222]
- 
        Common subexpression elimination depended on memory allocation order and could 
        eliminate different expressions if the executing environment changed, for 
        example if different operating systems were used.
 [EW13251]
- 
        In some cases, optimization of repeated assignments could remove an assignment 
        to an auto variable, even though it was still used.
 p = q; p->next = p; p->prev = p;
 could be transformed to
 p->prev = p->next = q;
 [EW13299]
- 
        When creating a temporary value from a common subexpression, the creation could 
        be lifted above assignments to clustered variables that were part of that 
        common subexpression. This caused the wrong clustered variable to be accessed.
 [EW13332]
- 
        Thumb functions declared __irqno longer generate an internal error. But note that__irqfunctions cannot be compiled as__thumb.
 [EW13337]
- 
        XLINK could erroneously report a type conflict for cases where some type 
        attributes (like constorvolatile) were part of atypedeftype.
 [EW13345]
- 
        If a loop contains multiple occurrences of variables that are only incremented 
        in the loop, the increments of those variables can be hoisted out of the loop. 
        The order of the hoisted increments no longer depend on memory allocation 
        order.
 [EW13352]
- 
        When compiling a new/deleteexpression in C++ code at optimizations of Medium or High, and 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.
 [EW13359]
- 
        A comma expression containing an assignment where a constant address was 
        assigned another constant, *(unsigned char *)0x1234 = 17, caused an internal error.
 [EW13375]
- 
        The assembler output generated from a string literal beginning with a tab 
        character could not be assembled.
 [EW13552]
- 
        If there were several calls with a different number of parameters via a relay 
        function to a vararg or K&R function, one of the parameters could be 
        destroyed.
 [EW13564]
- 
        Inline assembler with several functions in different modes (__arm/__thumb) in the same source file could cause an internal error.
 [EW13581]
- 
        In some cases, a common subexpression containing a clustered variable could be 
        hoisted across a definition of that variable, if it occured in the same basic 
        block as the common subexpression.
 [EW13593]
- 
        Incorrect code was sometimes generated when combining shift and zero extension 
        operations.
 [EW13915]
- 
        When doing char (8-bit) arithmetics causing overflow, the generated code could 
        make use of the overflowed value, that is, a larger value than 8 bits.
 [EW14191]
- 
        When compiling code containing a combination of left and right shifts, the 
        compiler performed an incorrect optimisation using a constant mask. This mask 
        was calculated for an unsigned int even when the actual type used was signed 
        int.
 [EW14688]
- 
        Compiling code which used a combination of shift left and shift right, the 
        compiler did an erroneous optimisation using a constant mask. This mask was 
        calculated for an unsigned int even when the actual type used was signed int.
 [EW14688]
V3.21A 2002-09-27
- 
        #pragma segment = <name>
 Declares a segment name that can be used in the segment operators __segment_begin and __segment_end. Example:
 #pragma segment = "MYSEG" __huge
- 
        __segment_begin(<name>)
 __segment_end(<name>)
 The __segment_begin operator denotes the start address of the segment with the name <name>, which must be a string literal and must have been declared in a segment pragma at an earlier point in the compilation unit. The __segment_end operator denotes the address immediately after the last byte in the segment. The type of these operators is pointer to void. If a memory attribute is entered in the segment pragma declaring the segment, the type is pointer to <memory> void, otherwise the type is a default pointer to void. The operator given in the example has the type "void __huge *".
 Example:
 __segment_begin("MYSEG")
- 
        #pragma required
 The #pragma required will introduce a requirement from a symbol to another symbol, i.e. if the first symbol is in the produced output when linking the other symbol should also be in that output. This is useful if, for instance, a function that handles certain data should only be used if there is any data to handle.
 Syntax: #pragma required=symbol where symbol is any statically linked function or variable. The #pragma must be placed in front of a symbol definition.
 An example:void func(void) { // handle segment S or longVariable here } #pragma required = func // longVariable requires f long longVariable @ "S"; // longVariable resides in segment S
- The option --diagnostics_tables file|directory produces all possible diagnostics to a file. The default extension is txt. Default filename, if only a directory is specified, is diagnostics_tables.txt. It should only be used as a separate option to the compiler. This option is usefull if you have used #pragma diag... but forgot to document why, etc.
- Libraries for big endian are now included.
- 
        Loop-invariant optimizations depended on OS memory allocation order.
 [EW13215]
- 
        Inlined code could in rare cases give the following error:
 Internal Error: [GoSyncStuff::FindPrecedingSync]: cannot find unique sync node.
 [12852]
- 
        The compiler now generates the Thumb mnemonics LDRSB and LDRSH instead of the 
        older LDSB and LDSH.
 [EW12310]
- 
        Loop optimizations could generate incorrect array index.
 [EW12325, EW12326, EW12409]
- 
        Code that handles small unaligned structures could generate an internal error.
 [EW12403]
- 
        Code for casting to signed and unsigned long long could sometimes result in 
        incorrect values.
 [EW12404]
- 
        Code generated to access to nonaligned structures could be incorrect.
 [EW12405, EW12406]
- 
        A constanttable inserted after a function that had been cross-jumped could 
        result in an internal error.
 [EW12407]
- 
        An optimization bug could cause incorrect code to be generated.
 [EW12408]
- 
        Short elements in a union stored in a register could be incorrectly aligned.
 [EW12410]
- 
        A cast operation could sometimes incorrectly be optimized away.
 [EW12512]
- 
        The code generated by the compiler could change depending on the compiler 
        execution environment. The generated code was correct but the size could 
        differ. The sensitivity to change in execution environment could be moving to a 
        different Windows OS, changing the environment settings, length of file paths 
        and other changes that could change the memory allocation order within the 
        compiler process.
 [EW11219, EW12580]
V3.20A 2002-06-18
- The runtime model has changed from version 3.11A. The current __rt_version is 4.
- 
        ARM instruction set version 5TE is now supported.
 To use it add command line option --cpu {target core or architecture name}.
- It is now possible to mix code compiled with small and large code models.
- The interworking code model is now supported through the new command line option --interwork.
- The calling convention is now ATPCS as default. Interwork must still be added if needed to a function with function-type attribute __interwork or globally with the command line option --interwork.
- Access to floating point flags has been re-engineered. Refer to the file MathFloatFlags.h for more information.
- Two functions from the ANSI C99 standard have been included: snprintf() and vsnprintf().
- 
        Evaluation of else-if could be performed incorrectly at high speed optimization 
        in Thumb mode.
 [EW12287]
- 
        The char pointer member of a structure object used as parameter was not passed 
        correctly to the called function. This occurred at high optimization levels.
 [EW12248]
- 
        The combination of Thumb mode and high speed optimization could lead to 
        incorrect code when testing bitfield values.
 [EW12227]
- 
        Structure return values from __pcs functions that are less than 32-bit and not 
        aligned to an even 4-byte address would be returned indirectly using an 
        implicit extra parameter.
 [EW10358]
- 
        Register mismatch in debug information between compiler and linker when output 
        was ELF/DWARF.
 [EW10703]
- 
        Library functions assert, strchr and strrchr could not be used with string 
        literals in C++.
 [EW10899]
- 
        The compiler could previously generate multiplication instruction with 
        undefined behavior: MUL R0,R0,R4.
 [EW11114]
- 
        The intrinsic functions __sfb/sfe could only be used once per segment, multiple 
        uses would result in link failure.
 [EW11122]
- 
        A small part of the runtime library was broken. It used the wrong register in a 
        BX instruction.
 [EW12060]
- 
        Certain __swi function definitions could result in an incorrect warning.
 [EW11247]
- 
        The compiler generated incorrect code for switch statements where the body code 
        and at least one case except the last did not end with a break or a goto.
        
 [EW11336, EW11337, EW11360]
- 
        The compiler could generate incorrect code for a bitfield value test at 
        high-speed optimization.
 [EW11371]
- 
        Nested loops using the same loop variable could be optimized incorrectly if the 
        increment or decrement of the loop variable preceded the inner loop.
 [EW11372,EW11423]
- 
        Read access to smaller union fields in register allocated unions could destroy 
        other union fields of different size.
 [EW11373, EW11381]
- 
        Some code optimization and analysis problems were corected. They either 
        resulted in "Internal error" or the compiler never terminated.
 [EW11374, EW11375, EW11376]
- 
        Corrected a problem where partial object assignments were interpreted as an 
        assignment of the whole object. This could cause incorrect elimination of 
        assignments.
 [EW11377, EW11418, EW11424, EW11427]
- 
        The compiler is now a little more restrictive when optimizing address 
        expressions. This avoids incorrect assumptions while compiling code that does 
        not conform to ANSI C.
 [EW11378, EW11422]
- 
        Variable initialization could in some cases be optimized away.
 [EW11380]
- 
        Sometimes loops that were unrolled to straight line code could be optimized 
        incorrectly.
 [EW11416, EW11425]
- 
        When for or while loops were fully unrolled, side effects in the test would not 
        be executed for the final iteration.
 [EW11417, EW11426]
- 
        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 C standard allows the transformation, since the behavior at overflow is unspecified. But the expressions are no longer transformed since it changed the expected behavior.
 [EW11490, EW10978]
- 
        Using integer division or modulo in __ramfunc could result in an internal 
        error.
        
 [EW11999]
- 
        Relay from located functions could result in:
 Internal error [OgModuleLabels::Def::Define]: Label already defined.
 [EW12011]
- 
        A number of code-generation and optimization bugs have been corrected.
 [EW11419, EW11420, EW11421,EW11862]
 
- 
        The file checkDefs.i included by cstartup.s79 was missing from the 
        distribution.
 [EW11223]
- 
        The code generated for __disable_interrupt() has been rewritten in a more 
        secure way.
 [EW11143]
- 
        Crossjump between two or more small functions could destroy LR is the distance 
        between them is too far.
 [EW12808]
V3.11A 2001-12-04
- The floating point library now has exception flags. Refer to the file MathFloatFlags.h for more information.
- Long long is now supported, except in the formatted I/O functions.
- A new command line option, --omit_types, omits function/variable type info in object output.
- 
        An assignment between two elements from packed structures could generate a 
        misaligned access.
 [EW10299]
- 
        Structure parameters to __pcs functions larger then 64 bit or not aligned to an 
        even 4-byte address were always placed on the stack.
 [EW10357]
- 
        __pcs functions could in some cases get incorrect backtrace information.
 [EW10359]
- 
        Several corrections in long long support.
 [EW10364]
- 
        Loop optimization could hoist an expression before its definition.
 [EW10421]
- 
        String literals now have the type "array of const char" in C++.
 [EW10542]
- 
        Values casted to and compared in a type smaller than 32-bit could be destroyed.
 [EW10569]
- 
        When compiling a while loop following immediately after a case label in a 
        switch, the compiler could crash if high optimization was used (-s9 or -z9).
 [EW10725]
- 
        The intrinsic functions __sfb, __sfe and __sfs yield an error when the referred 
        segment is not otherwise used in the module.
 [EW10757]
- 
        Cross call optimization could generate a fatal error in some cases where 
        several similar functions had multiple exits.
 [EW10807]
- 
        Register allocation could in some rare cases with extreme register pressure 
        generate a "coloring failed" error.
 [EW10868]
V3.10A 2001-10-02
- The runtime model has changed from version 2.10. The current __rt_version is 2.
- New floating point library with smaller code size and greatly improved speed.
- Debug information is improved, with better variable information and backtrace.
- 
        A switch statement of the form switch(a-b<=0) at higher optimization levels 
        than 3 caused the wrong case to be selected.
 [ARMC0021]
- 
        Inline expansion of memcpy() could produce the wrong result.
 [ARMC0022]
- 
        Assignment loop using loop index caused incorrect code at -z9.
 [ARMC0027]
- 
        Bitfields could not be larger than 255 bits.
 [LB397]
- 
        Global optimizer problems which resulted in internal error has been corrected
 [EW10178 (LB399)]
- 
        Global optimizer problems which resulted in incorrect code has been corrected.
 [EW10082, EW10102, EW10180 (LB401), EW10181 (LB402), EW10182 (LB403)]
- 
        Call via function pointer now sets the correct mode bit in return address.
 [EW10313]
- 
        A problem in the register allocation algorithm could cause "Internal error: 
        [CgDriver]: Coloring failed".
 [EW10087]
- 
        Too aggressive optimizations when shifting bitfields.
 [EW10080]
- 
        Call to a variadic __pcs function with K&R declaration with different 
        number of arguments could cause an internal error.
 [EW10083]
- 
        A faulty optimization rule could cause Thumb instructions to use illegal high 
        registers.
 [EW10292]
- 
        Header files for C++ not installed.
 [EW10294]
- 
        The gmtime() could cause corrupt tm structure values for arbitrary time values, 
        the tm_mday for example could turn negative. There was also a problem that the 
        mktime() function could corrupt tm structure values.
 [EW10363]
V2.10D 2001-06-27
- 
        Loop optimizations have been reorganized and several problems have been 
        corrected.
 [Lb 355,375,376,379,382,390,396]
- 
        Corrected a problem in the ARM mode peephole optimizations. Could cause an 
        unintialized register to be used.
 [ARMC0018]
- 
        Corrected a problem that caused compiler to loop if ARM mode was used and the 
        code had a large modulo expression.
 [ARMC0017]
- 
        Part of the exit sequence could be optimized away (restoring high registers in 
        Thumb mode).
 [ARMC0016]
- 
        Fixed problem where a constant casted to a pointer caused incorrect code 
        randomly.
 [ARMC0015]
- 
        CStartup used to have a reference to SVC_STACK that was neither used in the 
        code nor declared in the standard linker command file lnkarm.xcl.
 [ARMC0011]
- 
        #pragma swi_number can now be fitted to either the function declaration or the 
        function definition.
 [ARMC0009]
- 
        Fixed code for passing structures as parameters. The code was either incorrect 
        or the stack was not aligned correctly.
 [ARMC0007]
V2.10A 2001-02-21
- The compiler now supports Embedded C++.
- It is now possible to choose between big and little endian byte order.
- Support for the ARM9TDMI core has been added.
- 
        The following command line options have been added or changed:
        - 
            --ec++add support for ec++ syntax
- 
            --cpu [arm7tdmi | arm9tdmi]select processor
- 
            --endian [big | little]select memory format
- 
            --no_schedulingdisables instruction scheduling
 
- 
            
- 
        A program with struct accesses in different scopes but casted from the same 
        variable could be transformed incorrectly.
 [Lb 388]
- Too aggressive optimizations with partial updates of variables.
- A change of sign was sometimes introduced in unsigned character switches.
- 
        Incorrect code was generated in loops at high speed optimizations.
 [Lb 381]
- 
        An internal error was received when the > operator was used with unequal 
        types in loops at high optimizations.
 [Lb 380]
- 
        The recognition code for packed structures was incorrect.
 [Lb 378]
- 
        A problem occuring when accessing fields in packed structures has been 
        corrected.
 [Lb 374]
- 
        Accessing array members of struct return values could give an internal error.
 [Lb 365]
- 
        Correcting a problem occuring in Thumb mode on high optimization level when 
        adding a constant offest to an address (label).
 [ARMC0004]
- 
        The following code used to give an internal error:
 int fn_dbl(double);
 int fn_dbl(f) float f; { do_nothing(&f); return 97; }
 [Lb 364]
V1.30C 2000-10-14
- 
        A problem in cstartup has been corrected, constants where put after each 
        segment even when fall-through was used.
 [ARMC0003]
- 
        A problem sometimes resulting in an internal error "coloring failed" in Thumb 
        mode has been corrected.
 [ARMC0002]
V1.30A/B 2000-09-28
- 
        Support for handling interrupt functions has been added.
 The following function type attribute keywords have been added:- __irq - declares an interrupt function.
- __fiq - declares a fast interrupt function.
- __swi - declares a software interrupt function.
 
- 
        The following #pragma directive has been added:
 #pragma swi_number=<number>
 For more information about interrupt functions, see Manual corrections in this document, tutor\interrupt_example.c, inc\arm_interrupt.h, and src\lib\swi_handler.s79.
- 
        The following intrinsic functions have been added:
        - 
            __intrinsic int __sfb(void *)- returns address to beginning of segment
- 
            __intrinsic int __sfe(void *)- returns address to end of segment
- 
            __intrinsic int __sfs(void *)- returns size of segment
 
- 
            
- 
        Code for spilling and unspilling high registers in Thumb mode has been 
        corrected.
 [ARMC0001]
- A problem that under some circumstances could result in a never-ending compiler internal loop is corrected.
- Volatile objects referred by a pointer, are now handled correctly.
V1.20A 2000-05-28
- 
        The following C library functions will under certain circumstances be handled 
        as intrinsic functions and will generate inline code instead of an ordinary 
        library call: memcpy, memset, strcpy, strlen, strncpy, strcat, strcmp, strncmp
V1.10B 2000-01-14
- Minor corrections.
- Switch statements in ARM mode are now implemented more efficiently, using jump tables.
V1.10A 1999-12-30
- First release.