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

Important information

• News in EWARM 6.10.2:
  

  The --guard_calls command line option is introduced. Note, --guard_calls must always be used in applications written in EC++/C++ that need thread-safe library function calls. For more information see the Development guide.

  The --no_guard_calls command line option is removed.

  The --aeabi command line option has modified behavior: Guard calls are not used by default.
  Migration instructions from IAR C/C++ Compiler for ARM 5.x and 6.10.1 to IAR C/C++ Compiler for ARM 6.10.2:
  --aeabi (without --no_guard_calls) shall be replaced with --aeabi --guard_calls
--aeabi --no_guard_calls shall be replaced with --aeabi
  

• News in EWARM 6.20:
  

  A customer that have implemented the time() function must now rename it into __time32(). For more information see the Development guide.

• A special note on CMSIS integration:
  

  If your application source code include CMSIS header files explicitly, then you should not check the Use CMSIS check-box Project>Options...>General Options>Library Configuration>Use CMSIS. Some of the Cortex-M application examples includes CMSIS source files explicitly, do not check the said check-box in these projects.
  
  However, due to the evolution of the IAR C/C++ Compiler for ARM, older versions of CMSIS are incompatible with the current version of the compiler. One simple example of how to solve this issue is:
  a) Press F4 to bring up the erroneous source (header) file in the editor - in most cases named core_cm3.h.
  b) Right-click on the window tab of that editor window, choose File Properties....
  c) Add (or remove) any character to the file name - so the compiler won't find it any more.
  d) Modify project options: Check Project>Options...>General Options>Library Configuration>Use CMSIS.
  Steps a) to c) might need to be done for more than one file. Normally, the names of these files are core_cm0.h, core_cm3.h, core_cm4.h, core_cmFunc.h and core_cmInstr.h.
  
  For more information about CMSIS integration in the IAR Embedded Workbench for ARM, see the Development guide.

• The runtime library assumes that unaligned access is allowed when it is available in the architecture
  

  For ARM core architectures where unaligned access is permitted and offers the possibility to generate more efficient code, the runtime library is built to take advantage of this. For example the library for Cortex-M3 assumes that the UNALIGN_TRP bit is not set by the embedded application.

• Not using interwork when compiling for ARM architecture v4 is deprecated
  

  For now, this mode is supported like in earlier versions of the product, but new features, like C-RUN, will not have support for this mode.

• Deprecated features

  • --use_old_syntax

    The compiler option --use_old_syntax will be removed in future versions of the IAR C/C++ Compiler for ARM.

  • --interwork

    Future versions of the IAR C/C++ Compiler for ARM will assume --interwork when generating code for the ARMv4T architecture. There will be no option to generate non-interworking code for ARMv4T.

New features

• None.

Known Problems

• Assembler file listing containing initializers for a data object that has a type that uses __packed or #pragma pack, is incorrect.
  [EW23889]

• MISRA C:2004 rule 9.1 will not find all used uninitialized local variables.
  [EW24720]

• The overload resolution algorithm doesn't take into account template user conversion for argument deduction when finding out what built-in operator that is the best fit.
  [EW24930]

• Passing a parameter of type va_list to a C++ function, where the caller is defined in one object file and the callee in another, will result in a linker error if one of the two objects is built with EWARM 7.20 (or newer) and the other is built with EWARM 7.10 (or older).
  [EW25660]

• When compiling for VFP, the VLDR instruction is in some cases used to load (possibly) unaligned data, which can happen when __packed or #pragma pack is used. The result is a hard fault interrupt in cases where the address actually is unaligned.
  [EW25708]

• No error is emitted for some illegal aggregate types (example: a struct with a single zero-length array member).
  [EW25897]

• When an optimization removes the last use of a callee-saved register, the now unused register is in some cases no longer saved. This changes the stack layout, which is not reflected by DWARF debug information.
  [EW26026]

• Static storage duration variables of reference type initialized to an lvalue are not placed in ROM.
  [EW26028]

Program Corrections

• The compiler can incorrectly produce an error for large initializers.
  [EW25718]

• The lifetime of variables on the stack is not handled correctly over calls to setjmp. This might cause two variables with non-overlapping lifetimes to be assigned the same location on the stack and the value might not be preserved for the variable live at the setjmp call.
  [EW25735]

• Long long additions of 0xffffffff00000000 or subtractions of 0x100000000 can be incorrectly optimized.
  [EW25745]

• When generating Thumb-2 code at optimization level High, a byte assignment into an array on the stack can in rare cases result in an unpredictable STRB instruction (the stack pointer is used as offset register).
  [EW25778]

• Instruction scheduling could move a stack access (using a register other than SP) across a stack-pointer adjustment, which could lead to a corrupt stack if an interrupt occurs.
  [EW25810]

• On optimization level High, loops can be incorrectly optimized if they contain multiple basic blocks, one or more inline assembler statement, and array accesses passed as arguments to the inline assembler statements.
  [EW25814]

• Functions with block-local static pointer variables that are initialized with a variable address can be incorrectly optimized.
  [EW25864]

• On optimization level Medium or High, calls to strcmp, where an argument is a reference to an element in a const multi-dimensional char array, can be incorrectly optimized.
  [EW25868]

• On optimization levels Medium and High, partial accesses to scalar static variables can be incorrectly optimized.
  [EW25890]

• When the optimization goal is size, a loop containing an array element assignment where the right-hand side is a variable and the same variable occurs in the index expression (a[i] = i), the loop can be incorrectly optimized if the compiler can deduce that the loop body will be executed exactly once.
  [EW25893]

• __ALIGNOF__(variable) returns the alignment of the variable's type, not the actual alignment of the variable.
  [EW25990]

• Optimizing floating-point compares that contain a constant might change the constant slightly too much in rare cases.
  [EW26007]

• In rare cases, a volatile inline assembler statement could be removed if it was legal to remove the corresponding non-volatile inline assembler statement. This could happen only when a copy of the inline assembler statement was introduced by some optimization: the volatile attribute of the copy would be memory-dependent (uninitialized).
  [EW26047]

• The assembler-level optimizer could get trapped in a meta-stable state due to a sequencing issue in the flow of control analysis.
  [EW26088]

• Using pathnames with national characters (characters outside 7-bit ASCII) in ielftool does not work properly in some circumstances:
  • Specifying such characters for a raw binary, SimpleCode, or ELF output file results in a file in an incorrect location with an incorrect name.
  • The verbose console output is incorrect in most cases for such characters in input as well as output files.
  [EW26101]

• Vectorization of float accesses does not handle negative scaling or negative increments correctly.
  [EW26170]

• Loops where the loop counter is incremented both with a loop-invariant non-constant expression and a constant can trigger an internal error on optimization level High.
  [EW26175]

• Preprocessor macro expansion adds an unwanted extra space between some preprocessor tokens (in particular between '.' and 'foo' in #define EXTENSION .foo).
  [EW26193]

• On optimization level Medium or High, inline assembler statements can be incorrectly optimized if a variable occurs as an output parameter and the variable is assigned prior to the inline assembler statement.
  [EW26201]

• The compiler will produce an internal error after a real error for certain usages of enum types when using multi-file compilation.
  [EW26215]

• On optimization level High, loops equivalent to memcpy, memset, or memclr can be incorrectly optimized if the upper limit in the loop is a function call.
  [EW26223]

• The Global Optimizer could under certain circumstances generate non-canonical intermediate code. The structure of this (otherwise correct) code was not expected by the code generator, which results in an internal error.
  [EW26232]

• The compiler can terminate with an internal error if member function code for a class template uses the dynamic_cast operator from or to pointers or references to the class template type itself.
  [EW26248]

• Using #pragma weak to define a weak alias and then using that alias in the same compilation unit can result in the compiler terminating with an internal error.
  [EW26268]

User guide corrections

• New compiler option in 7.40.2 to save RAM space
  

  Syntax
  --no_var_align
  
  Description
  By default, the compiler uses alignment 4 for objects with a size of 4 bytes or more. Use this option to make the compiler align variable objects based on the alignment of their type.
  
  For example, a char array will get alignment 1, because its elements of the type char have alignment 1. Using this option might save RAM space, possibly at the expense of processing speed.
  
  See also, in the IAR C/C++ Development Guide for ARM:
  Alignment, page 317.
  --no_const_align, page 269.

Miscellaneous

• Available workarounds for device erratas:
  
  

  • ARM Cortex-M3 errata 463764
    Core may freeze for SLEEPONEXIT single instruction ISR. More information is available on infocenter.arm.com.
    Workaround generated for functions with attribute __irq with iccarm --enable_hardware_workaround=arm463764. Supported from EWARM 5.41.

  • ARM Cortex-M3 errata 602117
    LDRD with base in list may result in incorrect base register when interrupted or faulted. From EWARM 5.20.3 the compiler/library avoids the LDRD instruction with the base register in list.

  • ARM Cortex-M3 errata 752419
    ARM Cortex-M4 errata 752770
    Interrupted loads to SP can cause erroneous behaviour. From EWARM 6.21 the compiler/library does not generate LDR SP instructions with writeback to Rn. Otherwise we allow the extra reads since the stack resides in RAM where multiple reads are acceptable.

  • ARM Cortex-M7 errata 833872
    Flag setting instructions inside IT block might cause incorrect execution of subsequent instructions. From EWARM 7.40 the compiler will the skip the IT transformation on this particular code pattern.

  • ARM Cortex-M3 errata 838469
    ARM Cortex-M4 errata 838869
    Store immediate overlapping exception return operation might vector to incorrect interrupt. The user should follow the guidelines in the errata and implement the workaround proposed by ARM by using __DSB(void) in applicable cases.

  • Functional problem Core.1 in NXP device LPC2478: Incorrect update of the Abort Link register in Thumb state.
    Workaround generated with iccarm --enable_hardware_workaround=NXP_Core.1

  • Functional problem in Stellaris devices: Non-word-aligned write to SRAM can cause incorrect value to be loaded. More information is available on the Stellaris web site at www.ti.com/stellaris.
    Workaround generated with iccarm --enable_hardware_workaround=LM3S_NWA_SRAM_Write

  • Functional problem in Freescale Semiconductors MC9328MX1 (i.MX1), masks 0L44N, 1L44N, and 2L44N:
    The LDM instruction will in some cases not load the second register correctly. Workaround generated with iccarm --enable_hardware_workaround=920t-ldm2
    NOTE: The libraries in the current EWARM version are not built with this workaround. Use EWARM 6.50.6 and linker option --enable_hardware_workaround=920t-ldm2 to use libraries built with this hardware workaround.

• The implementation of va_args functions have changed in IAR Embedded Workbench for ARM 7.20.1. It is no longer possible to compile the output of the pre-processor from an earlier version of the compiler. The original source code must be pre-processed again, using IAR Embedded Workbench for ARM 7.20.1.

Release history

See release history.