IAR Information Center for Arm

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

Important information

• Compiler MISRA C C:1998/C:2004 support deprecation notice

  The MISRA C support is deprecated starting with EWARM 8.50.4 and will be removed in a future release.
  Refer to IAR C-STAT for full MISRA C support.

• Changes in implementation of CMSIS intrinsics in version 8.20

  The implementation of the CMSIS intrinsic interface is no longer based on IAR's intrinsics.h. As a consequence of that some intrinsics that was previously declared when the CMSIS header was included are no longer declared.

  Examples of these intrinsics include __LDREX(), __STREX() and __enable_interrupt().

• 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

• None.

Known problems

• [EWARM-7836, TPB-3395] On optimization level High the compiler can generate incorrect code when there is an assignment to a de-referenced pointer followed by two or more loops in sequence where the first loop reads an array or de-references a pointer of the same type or of type char* and the second loop modifies the assigned pointer. A triggering example is shown below. In this example the bug triggers when the Byte is type is either char or uint16_t. The observed effect in this case is that the assignment *value=0 is not performed.
  

          bool cvt16(const Byte bytes[], int size, uint16_t *value)
          {
            bool result = true;
  
            *value = 0U; 
  
            int16_t tCnt = (int16_t)size - sizeof(uint16_t);
            int16_t a = 0;
  
            while (a < tCnt)
            {
              if (0U != bytes[a])
              {
                result = false;
              }
              a++;
            }
            while (a < size)
            {
              (*value) <<= 8;
              (*value) |= bytes[a];
              a++;
            }
            return result;
          }
          

• [EWARM-7810, TPB-3394] The gnu format attribute (_attribute_((format))) is incorrectly marked as not supported. Using it generates spurious warnings.

• [EWARM-7786, TPB-3374] Under some circumstances, such as when the fields of a structure type are only ever accessed via a global pointer variable that is defined in a separate file from the accesses, debug information about the fields is not emitted.

• [EWARM-7762, TPB-3371] std::unique_ptr<T>, where T is an array type, is missing a default argument for the nullptr_t overload of the reset member function:

          reset(nullptr_t = nullptr);
          

• [EWARM-7752, TPB-3370] If a preinclude file is specified, the compiler uses its name as the name of the module, instead of using the name of the main source file. This mainly affects code coverage.

• [EWARM-7747, TPB-3369] With an optimization level of medum and higher, the compiler can generate incorrect initialization values for C++ objects with static storage duration that have constructors defined in the same modules. A triggering condition is when the constructor contains an if or switch statement. The bug does not trigger if the constructor is declared as constexpr.

• [EWARM-7688, TPB-3358] A floating-point expression that is cast to an integer type N, where one operand is a floating-point constant with a value that is exactly representable as an integer, and the other operand is an integer expression with type T, is evaluated in T, rather than the type N. For example, the expression (uint32_t)((uint16_t)a*32768.0) is evaluated in uint16_t rather than uint32_t, possibly leading to unexpected results.

  Workaround:
  Do not mix integer types of different sizes and floating-point arithmetic with integer-valued constants in the same expression.

• [EWARM-7540, TPB-3325] On optimization level High, the compiler can incorrectly move pointer-based loads and stores across the definition of the pointer variable. This problem can occur when a pointer is repeatedly de-referenced inside a loop, and the pointer variable is defined or first set inside the same loop.

  Workaround:
  Reduce the optimization level to Medium or lower.

• [EWARM-7528, TPB-3323] C++ in-class definitions of friend functions in template classes can sometimes be instantiated unnecessarily. This can lead to a variety of errors, including infinite template instantiation recursion and incomplete types being used.

• [EWARM-7470, TPB-3316] The compiler can terminate with an internal error for some C++ code when checking of MISRA-C: 2004 rule 11.4 is enabled.

• [EWARM-7442, TPB-3308] The compiler can terminate with an internal error when checking of MISRA-C: rule 5.3 (typedef reuse) is enabled, in the context of multi-file compilation (--mfc).

• [EWARM-7440, TPB-3309] On optimization level High, the compiler can generate incorrect code for functions that write to variables with static storage duration and have a loop nesting that is not strictly hierarchical (that is, when two loops intersect and neither is completely inside the other).

  Workaround:
  Reduce the optimization level to Medium or lower.

• [EWARM-7430, TPB-3304] The clang preprocessor macro __has_attribute(attr) incorrectly expands to 1 for gnu/clang attributes that are not actually supported.

• [EWARM-7313, TPB-3272] The compiler does not support the _attribute_((packed)) attribute correctly. For cases where this results in a bitfield that spans more bytes than would normally be required for its type, the compiler can terminate with an internal error, or, possibly, generate incorrect code.
  Example:

          struct __attribute__((packed)) {
            short a : 5;
            short b : 13;
            short c : 14;
          };
          

  The bitfield b is of a type that normally only requires two bytes, but in this case parts of it will reside in three different bytes (3 bits in the first byte, 8 bits in the second, and 2 bits in the third byte). This type of bitfield is not handled correctly.

• [EWARM-7305, TPB-3270] The C++17 structured binding feature (auto [x, y] = ...) does not work for any type where std::tuple_size is needed. Compilation fails with an error that states that no matching instantiation of std::tuple_size is found. Affected types include instantiations of std::pair, std::tuple, and std::array.

• [EWARM-6667, TPB-3086] The compiler can cluster variables that are initialized by copy and zero-initialized variables with static storage duration. When the total size of the variables initialized by copy is small compared to the total size of the zero-initialized variables, and if compressed initializers are not used, this can create a significant size overhead.

• [EWARM-5239, EW25660] 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).

• [EWARM-4921, EW24930] 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.

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

Program corrections

• In EWARM 8.50.6
  [EWARM-7859, TPB-3399] If #pragma weak is placed before a declaration and there is a definition of the same function/variable later, the compiler incorrectly does not make the definition a weak definition.

• In EWARM 8.50.4
  [EWARM-7735, TPB-3365] If the declaration of a function uses the __weak keyword and the definition does not, the function is incorrectly generated as a weak symbol.

• In EWARM 8.50.4
  [EWARM-7713, TPB-3363] The compiler can terminate with an internal error ('[Front end]: assertion failed at: "lower_name.c", line 2542 in mangled_encoding_for_function_type') in some cases that involve the use of a lambda function in certain scopes (like the condition scope in an if statement).

• In EWARM 8.50.4
  [EWARM-7531, TPB-3324] The compiler can fail to compile some C++ source code that involves constexpr array access with a non-zero index, erroneously emitting error Pe028: "expression must have a constant value", adding "[note]: attempt to access storage one position past an object treated as an array of one element".

• [EWARM-7460]

  Internal error when compiling a function with attribute __naked that ends with an inline asm statement that contains a literal pool load, if there is another function in the module. For example:

          __naked int* f(void) { __asm volatile("LDR R0, =x"); }
          

• [EWARM-7457] On optimization level High the compiler will remove offsets that it knows will be outside the variable. Even though addressing outside a variable is not supported by the language standard this turns out to be an idiom to address external memory blocks in embedded programming.

• [EWARM-7421, TPB-3295] Compilation can fail if a structure field has the same name as a type.

• [EWARM-7365, TPB-3306] When compiling for Armv8-M with the --cmse (secure mode) option set, a call to a function with the attribute __cmse_nonsecure_entry will unexpectedly return in non-secure mode.

• [EWARM-7358, TPB-3279] The compiler can terminate with an internal error ("[Front end]: assertion failed at: "lower_init.c", line 3396 in add_constructor_call") in some cases that involve C++ multiple inheritance.

• [EWARM-7357, TPB-3278]

  In some cases, the compiler does not properly take using declarations into consideration for conversion functions and erroneously emits an error. Example:

           struct X { operator bool() const; };
           struct Y { operator bool() const; };
           struct D: X, Y {
             using X::operator bool;
           };
           bool foo(D d) {
             return d;  // Incorrectly reported as ambiguous
           }

• [EWARM-7312, TPB-3271]

  The compiler can terminate with an internal error when code contains a constant that consists of a __section_begin or __section_end operator with an offset, converted to a function pointer. Example:

          #pragma section = "SEC"
          typedef void (*fun_t)(void);
          void
          foo(void)
          {
            fun_t fp = (fun_t)((long)__section_begin("SEC") + 1);
            fp();
          }
          

• [EWARM-7306] When compiling for baseline profile M devices (Cortex-M0/M0+/M1/M23), a function definition with the attribute __svc that contains a function call which is not inlined, results in an internal error.

• [EWARM-7270, TPB-3262] Mistakenly, the compiler never does emit warning Pa149 ("some enum values are not handled in this switch statement..."). This warning is for switch statements on an enum type, where there is no default case, all cases are for enum constants of the given type, and some enum constants are not handled.

• [EWARM-7264, TPB-3261] The compiler can terminate with an internal error ("assertion failed: lower_constant: bad kind") in some cases that involve braced initialization of a multi-level aggregate class like std::array with a dynamic value more than one level down, when exceptions are disabled.

  Example:

          #include <array>
          struct tValues
          {
            int val;
          };
          
          int fun();
          std::array<tValues, 1> arr{{ { fun() } }};
          

• [EWARM-6955, TPB-3196] The compiler sometimes fails to update the debug information for variables whose storage location changed by being moved from one processor register into another processor register.

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-M4 errata 776924
    VDIV or VSQRT instructions might not complete correctly when very short ISRs are used. IAR recommends the second workaround proposed by Arm: "Ensure that every interrupt service routine contains more than 2 instructions in addition to the exception return instruction." The background is that the compiler is unaware of interrupts since the Cortex-M architecture does not distinguish between ordinary functions and interrupt functions.

  • 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 inc\c\DLib_Threads.h header file contains support for locks and thread-local storage (TLS) variables. This is useful for implementing thread support. For more information, see the header file.

• 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.