IAR Information Center for Arm

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

Important information

Characteristics for the toolset in AARCH64 mode:
- The toolset, by default, supports generating code and data that is situated in one space that has a maximum size of 4 Gbytes. This is because static data will be accessed with an addressing mode that reaches +/- 4 Gbytes. Mechanisms exist to jump/call between such spaces.
- The produced code, by default, runs in execution state EL1.
Limitations:
- Big-endian code is not supported.
- Position-independent code is not supported.
- V8-A AARCH32 is not fully implemented. The 32-bit implementation is currently based on v7-A.
Compiler MISRA C C:1998/C:2004 support is removed in version 9.10
The Compiler MISRA C is still available through the compiler command line but 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 later
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.

In EWARM version 8.10 and later, wchar_t is 4 bytes wide.
If you have implemented the time() function, you must rename it into __time32(). For more information see the Development guide.
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.
Deprecated features
- --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-8839, TPB-3525]
Using alignas to set the alignment of a static data member with an in-class initializer results in a spurious error Pe1887 ("alignment attribute must also appear on definition").
Example:
```
        struct X
        {
          alignas(8) static constexpr short sh[2]{42, 17};
        };
        
```

[EWARM-8754, TPB-3516]

The warning Go029 can trigger erroneously for the first assignment to a field in a bitfield struct.

struct A
        {
          int x : 8;
          int y : 8;
        };
        struct A f(int x, int y)
        {
          struct A id;
          id.x = x; // Triggers Go029 erroneously
          id.y = y;
          return id;
        }

[EWARM-8304, TPB-3475]

In C++, the compiler can emit a spurious warning Pe940 ("missing return statement at end of non-void function") in a template context, if the immediately preceding statement is an if constexpr where the condition is false (that is, the else part is active), and the end of the else part is unreachable (for example, if the else part ends with a return statement).

Example:

        template<int n>
        class Class {
        public:
        static long test(long x) {
          if constexpr(n < 0) {
            return 0;
          } 
          else {
            return 1;
          }
        } // Warning[Pe940]: missing return statement at end of non-void function
        };

[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-4824, EW24720] MISRA-C:2004 rule 9.1 will not find all used uninitialized local variables.

Program corrections

In EWARM 9.10.2
[EWARM-8687, TPB-3510]
On optimization level Medium and higher, the compiler can generate incorrect code when the value of a de-referenced pointer is used in the condition part of an if statement, the same value is changed in the if statement, and both branches of the if contain a return statement.

The observable effect is that the erroneous code chooses the return value based on the updated value of the de-referenced pointer instead of the original value. The error can trigger for both examples below, as the compiler sees return 0 in the first example as part of the else branch of the if statement.
```
        int test_and_clearA(uint16_t mask, uint16_t *flags)
        {
          if ((*flags & mask) != 0)
          {
            *flags &= ~mask;
            return 1;
          }
          return 0;
        }
        int test_and_clearB(uint16_t mask, uint16_t *flags)
        {
          if ((*flags & mask) != 0)
          {
            *flags &= ~mask;
            return 1;
          }
          else
          {
            return 0;
          }
        }
        
```
In EWARM 9.10.2
[EWARM-8670]
When compiling for Armv4 (ARM7TDMI, ARM9TDMI) an interrupt service routine (ISR) with the __irq keyword will return from interrupt to an address four bytes before the interrupted instruction, if:
- the ISR contains a function call that is not inlined, or
- for some other reason the link register LR is saved to the stack.
In EWARM 9.10.2
[EWARM-8654]
Range checking for the opcode parameter is incorrect for these intrinsic functions:
- _MCR, MCR2, MRC, _MRC2: 0 to 8 is accepted, 0 to 7 is valid. Specifying 8 will result in an internal compiler error.
- _MCRR, MCRR2, MRRC, _MRRC2: 0 to 8 is accepted, 0 to 15 is valid. Specifying 9 to 15 will result in a range error.
- _arm_rsr64 and _arm_wsr64: 0 to 7 is accepted, 0 to 15 is valid. Specifying 8 to 15 will result in a range error.
In EWARM 9.10.2
[EWARM-8639, TPB-3507] On optimization level High, the compiler can generate incorrect code when a function that contains calls to functions declared as noreturn or C++ functions not declared as noexcept is inlined, and both the inlined function and the function it is inlined in modify the same variable.
In EWARM 9.10.2
[EWARM-8595] When the common subexpression optimization is explicitly disabled, the compiler can exit with an internal error for code containing shifts where the shift count is a constant expression containing calls to intrinsic functions. Note that the Embedded Workbench IDE explicitly disables common subexpression elimination on optimization levels None and Low.
In EWARM 9.10.2
[EWARM-8557, TPB-3490] The compiler can appear to hang when processing code that contains an initializer for a flexible array member (a language extension).
Example:
```
        struct X
        {
          int i;
          int arr[];
        } x = { 1, 2 };
        
```
In this case, the variable x will be allocated space for two int values, even though its type (struct X) is only as large as a single int.
[EWARM-8549, TPB-3488] Using the GCC packed attribute in such a way that at least one bit field is allocated into more bytes than its type would occupy, causes the compiler to terminate with an internal error (assertion failed at: "layout.c" ...).
Example:
```
        struct __attribute__ ((packed)) S {
          short a : 2;
          char b : 8;
          short c : 6;
        };
        
```
Note that the b bit field will be located partly in the first byte and partly in the second, but the type of the bit field (char) is only one byte. Changing the type of the bit field to something that is two bytes will make this work as intended, but this is not possible in all cases.
In EWARM 9.10.2
[EWARM-8441, TPB-3484] The compiler can terminate with an internal error when using the option --header_context in some cases involving the use of the #line directive.
[EWARM-8300, TPB-3471] In C++, a constant expression consisting of an address cast to an enumeration type can in some circumstances cause the compiler to terminate with an internal error ("[PaInitializerEDG - Traverse]: funny address type"). One such circumstance is when such a constant expression is used as the initializer for a variable.
[EWARM-8273, TPB-3465] In some cases involving zero-width bit fields, the compiler can terminate with an internal error ("[Front end]: assertion failed at: "layout.c", line NNNN in set_field_size_and_offset").
[EWARM-8271] When compiling for a core based on FPU architecture VFPv3 or later, sign-conversions can go wrong if either:
- the conversion is from a signed integer type to an unsigned integer type, and the value converted was previously converted from float, and the float value is a multiplication with a power of two, or
- the conversion is from an unsigned integer type to a signed integer type, and the value converted was previously converted from float, and the float value is a multiplication with a power of two.
Example:
```
        unsigned short f(float *a, int i) {
          return (int)(a[i] * 8.0f) + 0x8000ul;
        }
        
```
For this example, the return value is saturated to unsigned short, so any negative value becomes zero, and any value larger than 65535 becomes 65535.
[EWARM-8202, TPB-3457]
The compiler can generate incorrect code if strcpy, memcpy, memmove, or any other C library function that returns its first parameter is used for changing the value of a local variable at least twice in the same function. As an example, the function f below will return 1 if b->a1 is 10, regardless of the value of b->a2, because the analysis misses that memcpy(&a, &(b->a2)) changes the value of a.
The problem only occurs when the same local variable (a in the example) is changed multiple times by a C library function that uses the returns 1 function effect pragma.
```
        int f(struct B const *b)
        {
          int a;
          memcpy(&a, &(b->a1));
          if (a == 10) {
            memcpy(&a, &(b->a2));
          }
          if (a != 20) {
            return 1;
          }
          return 0;
        }
        
```
[EWARM-8145] The file cmain.s incorrectly contains the labels _main and _call_main.They have no documented use and they are not reserved, so they should be available for other use.
[EWARM-8009, TPB-3428] If the construction part of a new expression throws, the compiler should arrange for the storage allocated by operator new to be deleted. However, in most cases the compiler incorrectly emits this deletion also for exceptions thrown by other parts of the expression of which the new expression is part.
Example:
```
        throw new MyError(x);
```
In this case, the compiler will emit code to always call operator delete for the memory allocated by operator new, leading to possible accesses to already deleted memory and/or double delete.
[EWARM-7997, TPB-3427] Using the --enum_is_int option when compiling a C++ source file that includes the C++ system headers giving input/output facilities might generate faulty code.
[EWARM-7949, TPB-3426] Using GNU statement expressions (an experimental feature enabled by extended language support) in C++ causes the compiler to terminate with an internal error assertion failed: push_or_repush_object_lifetime.
[EWARM-7813, TPB-3391] Forgetting to put parentheses in a function call should result in warning Pa131, but for some intrinsic functions, like __disable_interrupt, the compiler fails to emit this warning.
[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-7747, TPB-3369] With an optimization level of medium 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-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-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.

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

release history