- Important information
- New features
- Known problems
- Program corrections
- User guide corrections
- Miscellaneous
- Release history
Important information
- 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 widewchar_t
but the object file is marked as ifwchar_t
is 2 bytes wide.In EWARM version 8.11
Looking only at thewchar_t
is 4 bytes wide and the runtime attribute is set accordingly.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 namedcore_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 arecore_cm0.h
,core_cm3.h
,core_cm4.h
,core_cmFunc.h
, andcore_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-5717, EW26583] The result of a compile time computation of a floating point expression that result in a subnormal number can be different from the result computed at run time. (Old id 26583)
-
[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
-
The compiler can generate incorrect code for min and max-like qmark expressions when the condition compares two variables and the value of the expression is the value of either variable casted to a narrower type. The same bug can also trigger for if statements where the condition compares two variables and the then and else clause only assigns the value of either variable to another variable with a narrower type.
An example of the first case is shown below. The triggering criteria is the qmark expression, the if statement is there to prevent the compiler from removing the qmark.
int b; void e(unsigned int a, int c) { unsigned int d = (a > c) ? (unsigned short)c : (unsigned short)a; if (d) b = d; }
-
[EWARM-6322] On optimization level High, when FPU support is enabled, and the target FPU has 32 D registers, the compiler can generate incorrect code for loading floating-point constants that can be represented with a 1-bit exponent and a 6-bit mantissa.
-
[EWARM-6309, TPB-2989] On optimization level High, the code generated by the compiler can differ between invocations for source code where 1. the value of a local variable is conditionally set to two different constant values, 2. all uses of this variable are part of an identical subexpression, and 3. at least one but not all of these subexpressions is part of a larger bit-wise OR. This error does not affect the correctness of the code.
This code can trigger the issue:
int f(int x) { int a = (x == 5 ? 10 : 7); int b = 3 * a; int c = 7 | (3 * a); return b + c; }
while this code can't
int f(int x) { int a = (x == 5 ? 10 : 7); int b = 3 * a; int c = 7 - (3 * a); return b + c; }
As a special case, the issue can be triggered by bitfield struct assignments when the address of the struct is conditionally set to two different constant values, if all uses of the struct address are part of identical subexpressions. In this case, the subexpression that contains the bit-wise OR is part of the bitfield assignment.
-
[EWARM-6306] Using the intrinsic function _RBIT() or _rbit() on an architecture that does not support the instruction RBIT can cause an internal error on optimization level Medium or higher.
-
[EWARM-6279, TPB-2975] The library static variable _Isdst_rules is defined in both the 32-bit and the 64-bit code for time-handling. This can give an redefinition error at linkage.
-
On optimization level High, the compiler can crash with an internal error or possibly generate incorrect code when compiling loops like the example below. The necessary conditions to trigger this problem are: a) The loop variable is a pointer that is stepped using pointer arithmetic. b) Inside the loop, the loop variable is indexed by a sum of two values that are not changed within the loop.
void f(int *x, int b, int c, int d) { for (int *a = x; *a < 1 ; a = a + d) { a[0] = a[c + b]; } }
-
[EWARM-6250, TPB-2963] On optimization level None the compiler can exit with an internal error when compiling code that contains an anonymous union where one of the data members is a bitfield.
-
[EWARM-6240, TPB-2961] When performing MISRA C checking in C++ mode, the compiler can erroneously report a violation of rule 12.5 (operands of && and || must be primary expressions) for the right-hand operand if that operand is not of bool type.
-
The compiler can fail to compile files with C++ code that use variadic function templates with default template arguments.
If a variadic function template has a default template argument that contains a pack expansion that uses an enclosing non-variadic parameter, a
substitution failure can result. This in turn will cause one of a number of errors, typically "no instance of ... matches the argument list".Example:
struct C {}; template <typename... Ts> struct A; template<typename, typename> struct B { static constexpr bool v = false; }; template<bool... T> struct F; template <bool... Bs> using E = B< F<Bs...>, F<Bs...> >; template<typename T, typename... _Us> struct D { static constexpr bool v = true; }; template<typename Ts, typename ...> struct H { template<typename... Us, bool b = E<D<Ts, Us>::v...>::v> H(Us&&... us); }; // Error "no instance of constructor ... matches the argument list" here H<A<C(int)>> h{1};
-
[EWARM-6198, TPB-2948] In some cases involving constexpr constructors of objects with class subobjects, the compiler can spuriously emit error Pe028 ("expression must have a constant value") with the (incorrect) note "access to uninitialized subobject".
-
[EWARM-6184, TPB-2943] The constructors and compound assignment operators of the explicit specializations of the std::complex template (for float, double, and long double) take component values by reference instead of by value.
-
[EWARM-6183] Using one of the ACLE intrinsic functions (__arm_rsr, __arm_rsr64, __arm_rsrp, __arm_wsr, __arm_wsr64, or __arm_wsrp) to access special registers in a C++ inline function can cause the compiler to terminate with an internal error.
-
[EWARM-6182, TPB-2944] A failed assert doesn't write the argument expression in the output.
-
[EWARM-6143] On optimization level High, the compiler can generate incorrect code when a pointer is assigned a value that is equal to it own address. The problem only occurs when compiling for the Thumb2 instruction set and is more likely to trigger when the assigned pointer is a field in a struct variable.
-
[EWARM-6116, TPB-2915] The #warning preprocessor directive now generates a separate diagnostic, instead of the same one as the #error preprocessor directive, only with a different severity.
-
C++14 constexpr void expressions can cause the compiler to terminate with an internal error ("[Il2cvm - CollectLiterals]: Unexpected constant kind.").
Example:
constexpr void foo() { } int main() { foo(); }
-
[EWARM-6079, TPB-2918] The compiler can terminate with an internal error instead of diagnosing the error when an array is declared with a size that is an address cast to an integer type.
-
On optimization level High, the compiler can generate incorrect code when simplifying address expressions in loops, if the address expression is inside another loop that is nested inside the first. As an example, consider the loop below. The compiler will simplify the array expression in two steps, first in LOOP C then in LOOP A, but in the second step it moves the initialization to a location where cc is not defined without replacing it with its initial definition. This problem will only occur when there is an extra level of nesting between the loops.
int f(int *data, int x, int c, int rc) { int v = 0; /* LOOP A */ for (int r = 0; r < rc; r++) { /* LOOP B */ while (!v) { /* LOOP C */ for (int cc = c + 1; (cc < (c + x)); cc++) { v = (data[cc * rc + r]); /* SIMPLIFY */ } } } return v; }
-
The following source code gives an erroneous error:
const std::function<int*(int*)> func = [](int *pn){ return pn; };
-
The parser does not correctly parse function modifiers like override when the underlying function declarator is parenthesized.
Example:
struct A { virtual void (*f())() = 0; }; struct B : A { virtual void (*f())() override; };
User guide corrections
- None.
Miscellaneous
-
Available workarounds for device erratas:
-
ARM Cortex-M3 errata 463764
Core might freeze forSLEEPONEXIT
single instructionISR
. More information is available on infocenter.arm.com.
Workaround generated for functions with attribute__irq
withiccarm --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 theLDRD
instruction with the base register in list. -
ARM Cortex-M3 errata 752419
ARM Cortex-M4 errata 752770
Interrupted loads toSP
can cause erroneous behaviour. From EWARM 6.21 the compiler/library does not generateLDR SP
instructions with writeback toRn
. 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 withiccarm --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 withiccarm --enable_hardware_workaround=LM3S_NWA_SRAM_Write
-
Functional problem in Freescale Semiconductors MC9328MX1 (i.MX1), masks 0L44N, 1L44N, and 2L44N:
TheLDM
instruction will in some cases not load the second register correctly. Workaround generated withiccarm --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.