IAR Information Center for ARM

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

Important information

• Changed size of wchar_t in version 8.10 and 8.11

  Object files following the ARM ABI has a runtime attribute indicating the size of wchar_t.

  In EWARM version 7.80 and earlier, the size of wchar_t was 2 bytes wide and the runtime attribute was set accordingly.

  For EWARM version 8.10, the size of wchar_t was 4 bytes wide but the value of the runtime attribute was not updated. Thus in 8.10 code is generated with 4 byte wide wchar_t but the object file is marked as if wchar_t is 2 bytes wide.

  In EWARM version 8.11 wchar_t is 4 bytes wide and the runtime attribute is set accordingly.

  Looking only at the wchar_t aspect this has the following implications:

  • Combining object files built with 7.80 and 8.10 will not trigger any linker warning but if the application uses wchar_t, the behavior will be unpredictable.

  • Combining object files built with 8.10 and 8.11 will trigger a linker warning but the application should work even if it uses wchar_t.

  • Combining object files built with 7.80 and 8.11 will trigger a linker warning and if the application uses wchar_t, the behavior will be unpredictable.

• Changed C-STAT behaviour in version 7.60
  

  • The analysis engine has been improved to increase the analysis precision for both existing and added coding rules. This can have the effect that the number of issued messages for a file or project can differ compared to previous versions of C-STAT, even if the enabled checks are exactly the same.

  • C-STAT settings in an old IAR Embedded Workbench IDE or Eclipse project will be updated. Some checks will be renamed (they retain their enabled or disabled settings), some checks are removed, and many new checks are added (see above).

  • Importing settings for C-STAT checks from a file will use the same logic as used when updating the project settings, if the settings file is created with an old version of C-STAT.

• If you have implemented the time() function, you must rename it into __time32(). For more information see the Development guide.

• 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
  

• A special note on CMSIS integration:
  

  If your application source code includes CMSIS header files explicitly, then you should not select Project>Options...>General Options>Library Configuration>Use CMSIS. Some of the Cortex-M application examples include CMSIS source files explicitly. Do not select the option Use CMSIS 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) Remane the file - so the compiler won't find it any more.
  d) Modify project options: Select 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.

• 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

• Support for the C11 language standard
  The compiler and libraries add support for the latest C language standard ISO/IEC 9899:2012.
  

  • The new C library binary object interface is incompatible with earlier EWARM versions.
  • C11 is the default language. C89 may be used as well (not 100% backwards compatible).
  • The C11 thread mechanism is not supported, and atomic is only supported for certain ARM cores.
  • Support for TLS variables and secure C functionality is included.

• Support for the C++14 language standard
  The compiler and libraries now support the latest C++ standard ISO/IEC 14882:2015.

• The new C++ library binary object interface is incompatible with earlier EWARM versions.
• It is not possible to upgrade an earlier EC++ or earlier C++ application into using the new C++ without porting the code, i.e. the C++ language is not backwards compatible
• The compiler supports C++ with or without exceptions and RTTI.
• The compiler supports atomic for certain ARM cores.
• Embedded C++ and Extended Embedded C++ have been removed.

• The compiler now has proper support for encodings. This means that you can use UTF-8, UTF-16, UTF-32, or the system locale in strings and characters.

Known Problems

• An 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]

• Sometimes vget_lane_xxx or vgetq_lane_xxx can generate an internal error.
  [EW26156]

Program Corrections

• On optimization level High, speed, do loops with a post increment or post decrement operation in the loop test can be optimized incorrectly.
  [EW26455]

• In some very rare cases the compiler can end up in an infinite loop.
  [EW26475]

• Modulo expressions where the divisor is -1 or U{CHAR,SHRT,INT,LONG}_MAX are not handled when the divisor is extended to a larger unsigned type.
  [EW26479]

• On optimization level High a for or while loop that is preceded by an if statement where the condition is identical to the loop condition can be optimized incorrectly, if any of the variables in the test is modified between the if statement and the loop test, and the variable has a type that is smaller than int.
  [EW26492]

• The AFE1 assembler cannot handle characters in comments with values over 0x7F in default mode.
  [EW26495]

• In EWARM 8.11.2:
  The compiler can terminate with an internal error in C++ mode when an assignment to a structure with bitfields is made using list-initialization.
  [EW26520]

• In EWARM 8.11.2:
  In some rare cases, conditions where a variable is compared to a constant can be optimized incorrectly on optimization level High or Medium.
  [EW26525]

• In EWARM 8.11.2:
  The function isblank() incorrectly returns true for characters that isspace() returns true for.
  [EW26556]

• In EWARM 8.11.2:
  Variables defined with __ro_placement are not accessed the correctly when compiled for RWPI.
  [EW26569]

• In EWARM 8.11.2:
  The functions iswctype and wctype are missing functionality for the blank operator.
  [EW26581]

• In EWARM 8.11.2:
  putchar(-1) erroneously assumes that -1 is EOF when the standard says it should be handled as the character 0xFF.
  [EW26588]

User guide corrections

• None.

Miscellaneous

• Available workarounds for device erratas:

  • ARM Cortex-M3 errata 463764
    Core might 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 might 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 because the stack resides in RAM where multiple reads are acceptable.

  • ARM Cortex-M7 errata 833872
    Flag setting instructions inside an 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. 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 an 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.

• RTOS Threads and TLS

  The compiler supports placing static variables into TLS, thread local storage (_Thread_local for C and thread_local for C++). The library places certain state-preserving variables in TLS as well. The compiler will generate a target dependent code sequence that looks like:

  CALL __aeabi_read_tp() ; Load start of TLS area for thread into R0.
ADD R0, 20 ; Add offset to TLS variable.
LD R1, @R0 ; Load the TLS variable into R1.

  The name __aeabi_read_tp is target dependent (can be __taabi_read_tp, __iar_read_tp, etc).

  The TLS for the primary thread, starting in cstartup, is handled automatically. For each manually created thread the following must happen:

  • Use __iar_tls_size() to get the size of the TLS.
  • Allocate memory for the TLS somewhere. TLSp points to that memory.
  • Call __iar_tls_init(TLSp) to statically and dynamically (C++) initialize the TLS.

  Note that it is possible to postpone the TLS creation of the primary thread in the same way that dynamic initialization can be postponed.

  If using C++, each thread to be destroyed should call the function

  void __call_thread_dtors(void);

  before the TLS is destroyed for the thread. The compiler uses locks for file handling, heap handling, etc. The following lock interface must be implemented (the max number used in C is _MAX_LOCK, C++ uses some of these locks as well):

  void __iar_system_Mtxinit(__iar_Rmtx *); // Initialize a system lock
void __iar_system_Mtxdst(__iar_Rmtx *); // Destroy a system lock
void __iar_system_Mtxlock(__iar_Rmtx *); // Lock a system lock
void __iar_system_Mtxunlock(__iar_Rmtx *); // Unlock a system lock

  The following lock interface is optional to be implemented (max number is FOPEN_MAX). The interface handles locks for each file stream:

  void __iar_file_Mtxinit(__iar_Rmtx *); // Initialize a file lock
void __iar_file_Mtxdst(__iar_Rmtx *); // Destroy a file lock
void __iar_file_Mtxlock(__iar_Rmtx *); // Lock a file lock
void __iar_file_Mtxunlock(__iar_Rmtx *); // Unlock a file lock

  An application that is multi-threaded must call

  void __iar_Initlocks(void);

  before any lock is used.

  All available locks will always be initialized, even if they aren't used by the application. The application must call

  void __iar_clearlocks(void);

  to destroy the locks. It should be called after atexit and _Close_all.

  To enable thread and TLS support, use the linker option --threaded_lib. If the application uses function-local static varaibles in C++ it should use the compiler option --guard_calls as well. See inc/c/DLib_Threads.h for proper declarations.

• va_args

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

Release history

See release history.