Release history for IAR C/C++ Compiler for ARM

V6.10 2010-11-04
V5.50 2010-04-21
V5.41 2009-12-14
V5.40 2009-07-10
V5.30 2009-01-23
V5.20 2008-06-24
V5.11 2007-12-11
V5.10 2007-06-12
V4.41A 2006-12-08
V4.40A 2006-06-03
V4.31A 2006-02-03
V4.30A 2005-06-23
V4.20A 2005-01-10
V4.11A 2004-06-10
V4.10B 2004-03-09
V4.10A 2004-02-21
V3.40C 2003-12-12
V3.40B-P1 2004-10-06
V3.40A 2003-07-03
V3.30B 2003-03-18
V3.30A 2003-02-18
V3.21A 2002-09-27
V3.20A 2002-06-18
V3.11A 2001-12-04
V3.10A 2001-10-02
V2.10D 2001-06-27
V2.10A 2001-02-21
V1.30C 2000-10-14
V1.30A/B 2000-09-28
V1.20A 2000-05-28
V1.10A 2000-01-14

V6.10 2010-11-04

New features

The product now uses the current C standard defined in 1999, known as C99, as the default C language. The previous major version of the product used the former C standard defined in 1989, known as C89. C89 can still be used in the compiler by using the --c89 option. The product will not be totally backwards-compatible though, because the support for some C99 features has been withdrawn. Variable length arrays, VLAs, in C99, are not supported in the default C language. They can be enabled with the option --vla. The C library supports all C99 functionality, and more, but only if used with the C99 language or with any C++ language. If used with the C89 language, C99-added functionality will not be allowed.
The implementation of EC++ and EEC++ has not changed in any major way.
Support for the C++ language has been added. By default, it fully supports the 2003 C++ standard, but can be used with exceptions and/or runtime type information disabled by using --no_exceptions and --no_rtti respectively.
Thread-safe libraries
The DLIB library now supports being used in a threaded environment. Some library systems, like the heap and the file structure, will be guarded by locks. Other library systems, like locale and errno, will have their static data allocated in thread-local storage. The DLIB thread support can either be supported by your chosen RTOS or can be manually implemented. For more information see the Development guide.
The compiler and assembler now automatically know where the library's system headers reside. You can control the compiler using the options:
- --dlib_config, to choose a configuration in the DLIB library.
- --system_include_dir, to override the directory to use as system header base.
- --no_system_include, to turn the automation off.
The compiler can now optimize some floating-point expressions more agressively by using the option --relaxed_fp. If enabled, the compiler tries to reduce the floating-point type used in floating-point expressions. This can cause a small loss of accuracy.

Program corrections

The library function fpclassify() handles normal and subnormal numbers correctly.
[EW21098]
Small memcpy calls are no longer transformed to assignments unless both the source and destination addresses have correct alignment.
[EW21193]
The compiler now checks that different kinds of variables are no placed in the same section.
[EW21351]
An internal error should no longer occur if __segment_begin() or __segment_end() is used in conditional code.
[EW21770, EW21838, EW21905]
Loops that decremented an unsigned loop counter past zero could in some cases be incorrectly optimized.
[EW21795]
Now all system headers do not generate MISRA errors.
[EW21799]
When optimizing, the the compiler now handles an initializer containing a function pointer with an offset.
[EW21870]
The endian attribute is not supported for pointers or arrays. Now an endian attribute can no longer be specified for pointers or arrays.
[EW21887]
Reversal of byte order is now correctly performed also for combinations of endian attributes and unaligned accesses. Previously, this was in some cases not handled.
[EW21888]
At optimization level High, speed-optimizing small loops similar to
```
      int test(int n)
      {
        while (n-- > 0)
          if (!foo(n))
            break;
        return n;
      }
      
```
could in some cases be incorrectly unrolled and cause an internal error.
[EW21949]
A class with a member that is a nameless struct, or an array of nameless structs, where at least one of the members is not a PoD, could cause an internal error while compiling.
[EW21958]
A while loop with a preincrement or predecrement in the loop test could be incorrectly optimized if the final part of the loop body was a do loop.
[EW21999]
The compiler will no longer merge instruction sequences (through cross call or cross jump optimizations) that are not equal, due to the register operand of a Thumb-2 compare-and-branch instruction (CBZ or CBNZ).
[EW22000]
When an enum is specified as a parameter or return type before it has been defined, the compiler will no longer record the wrong num size (attribute Tag_ABI_enum_size) in the ELF file.
[EW22013]
In Thumb-2, the compiler no longer issues an internal error in an attempt to widen MULS.N to MULS.W (which is not a Thumb-2 instruction) to achieve a 4-byte alignment of a following instruction or label.
[EW22018]
The compiler can now handle a function symbol as an argument to compiler optimized functions like memcpy.
[EW22052]
In EWARM 6.10.2:
Nested for loops where the inner loop's initial or final value was the outer loop's variable, multiplied with a constant scaling factor or with a constant offset, no longer causes an internal error on high optimization.
[EW22078]
In EWARM 6.10.2:
Some while loops with multiple exits no longer causes an internal error on high optimization.
[EW22080]
In EWARM 6.10.2:
Constant data is now placed in the .rodata section if the compiler has not generated a direct ADR reference. If there is an ADR reference, the constant data is placed in the .text section.
[EW22081]
In EWARM 6.10.2:
Standard C++ is now enabled also for the kickstart products.
[EW22089]
In EWARM 6.10.2:
Now the MISRA-C:2004 rule 20.2 checker can handle a long preprocessor symbol define.
[EW22117]
In EWARM 6.10.2:
For Cortex-M3, the compiler no longer attempts to generate a sub-routine for identical instruction sequences (cross-call) that end with a call to a software interrupt function (SWI), which would result in an internal error.
[EW22118]
In EWARM 6.10.2:
The compiler no longer removes code that uses the result of an STREX instruction (the instruction can be generated by using the __STREX intrinsic function).
[EW22119]
In EWARM 6.10.2:
The compiler no longer uses a signed 16-bit value as the immediate operand for the MOVT instruction. A 16-bit unsigned value is used instead, because MOVT expects an immediate value between 0 and 65535.
[EW22121]
In EWARM 6.10.2:
Evaluating a function address without using the result no longer causes an internal error.
[EW22146]

V5.50 2010-04-21

New features

The following C library floating-point functions, for devices without VFP, have been optimized for speed and size:
sqrt, sqrtf, modf, modff, fabs, fabsf, fmod, fmodf, floor, floorf, ceil, ceilf, ldexp, ldexpf, frexp, frexpf.
The following C library floating-point functions, for devices with VFP, have been optimized for speed and size:
sqrt, sqrtf, modf, modff, fabs, fabsf, fmod, fmodf, floor, floorf, ceil, ceilf, ldexp, ldexpf, frexp, frexpf, asin, asinf, acos, acosf, atan, atanf, atan2, atan2f.

Program corrections

While optimizing a function that contained code that prevented the end of the function to be reached, the compiler would erroneously leave a label after the last reachable instruction. This label was later interpreted as a leak of flow-of-control out of the function and an internal error was generated.
[EW21541]
A call to the map index operator now default-constructs the value if the key is not found even for base types.
[EW21592]
Using designated initializers (a C99 feature available in EC++ when IAR extensions are enabled) with a static storage duration object that needed C++ dynamic initialization could cause incorrect initialization.
[EW21649]
The use of intrinsics for LDC and STC could in some cases crash the compiler (access violation).
[EW21657]
A function, f, updating a global variable, could be incorrectly optimized, if
- f had multiple return statements,
- at least one of the return statements was inside a loop, and
- f was inlined in another function.
[EW21666]
For a function call where the compiler inserts a call to memcpy to construct a stack parameter, the register R1 is no longer assumed to survive the call to memcpy.
[EW21668]
The compiler no longer generates unaligned memory accesses for Cortex-M0.
[EW21687]
The compiler no longer generates branch instructions without size specifiers (.W or .N) for Thumb-2 capable cores (in Thumb mode), because doing so sometimes could result in an internal error.
[EW21699]
In EWARM 5.50.5:
Using an enumerator constant directly as a floating-point value no longer produces a corrupt value.
[EW21704]

In EWARM 5.50.5:
Array pointer decay of a block local static array with template parameter dependent size no longer results in an internal error.
Example:

              template struct Q
              {
                C * get()
                {
                  static long x[sizeof(C)];
                  return (C *)x;
                }
              };

[EW21728]

In EWARM 5.50.5:
The instruction scheduling for ARM11 no longer issues an internal error when scheduling a PKHBT instruction with a shifted operand.
[EW21745]
In EWARM 5.50.5:
The USAT instruction (for unsigned saturation) is now generated with correct bitwidth also in Thumb-2 mode (was off by one).
[EW21768]
In EWARM 5.50.5:
Cast from double to long long no longer generates faulty values for very large inputs with a non-zero fractional part. Values in the range [2^32, 2^52] were affected.
[EW21786]
In EWARM 5.50.5:
An internal error no longer occurs for conditions where the test is a ? : expression on the form:
if ((condition1 && condition2) ? 1 : 0)
[EW21807]
In EWARM 5.50.5:
Range checks for the address of a function parameter is now translated correctly: it could earlier in some cases result in internal error.
[EW21826]
In EWARM 5.50.5:
The compiler is now able to inline a function that in its body calls a function with the __noreturn attribute.
[EW21841]
In EWARM 5.50.7:
An internal error is no longer issued when multiple constant-table references are placed in the same IT-block for a function that is so large that an LDR (immediate) instruction cannot reach outside the function.
[EW21968]
In EWARM 5.50.7:
Loops that contain conditional accesses through an invariant pointer variable are no longer incorrectly optimized.
[EW21992]
In EWARM 5.50.7:
A signed division of an expression with a negative divider no longer gets optimized into using an unsigned division.
[EW22043]

V5.41 2009-12-14

New features

None.

Program corrections

cstartup_M.c now includes default interrupt handlers.
[EW21314]
Expressions on the form
if (expr < 0) v = -expr;
are no longer optimized incorrectly.
[EW21340]
A test inside a loop is no longer optimized incorrectly if
a) the loop had constant values for the initial and the final iteration,
b) the test compared an expression to a constant, and
c) the calculation of the expression would overflow or underflow for either the initial or final iteration.
[EW21363]
Complex |-expressions no longer cause infinite loops during optimization.
[EW21380]
Registers might be spilled to the stack frame when there are more live variables than registers. A spilled large register parameter (more than 8 bytes) no longer results in an internal error.
[EW21386]
The linker is now more relaxed concerning attribute checking when linking with explicitly specified libraries.
[EW21387]
Absolute addressed variable accesses no longer loose the volatile attribute during optimization.
[EW21400]
Debug information for classes inheriting from a base class whose primary base was inherited virtually is no longer generated incorrectly. The old problem could result in incorrect display of base classes in C-SPY.
[EW21411]
An error from the assembler in inline assembler code is no longer reported as a compiler internal error.
[EW21436]
The compiler now encodes the character value 255 in a string literal using an escape sequence, to work around the fact that the assembler interprets such a value as end of file.
[EW21443]
Registers are no longer renamed in situations where unused registers become used after renaming, to avoid situations where such registers would not be saved on the stack.
[EW21449]
The compiler now generates correct code instead of reporting an internal error in situations where an entry in a constant table is duplicated so that it can be reached by all its references.
[EW21471]
In EWARM 5.41.2:
Integral expressions in loops are no longer optimized incorrectly when the expression adds or subtracts a constant to/from a variable (x + ... + C), and the variable is assigned the same constant subtracted/added from/to the loop index variable (x = i - C).
[EW21493]
In EWARM 5.41.2:
Two tests on the form
expr1 > c1 && expr2 < c2
or
expr1 < c1 || expr2 > c2
are no longer incorrectly optimized as a range test when expr1 is not identical to expr2.
[EW21498]
In EWARM 5.41.2:
A bitwise and operation between a constant and a value loaded from memory will sometimes be transformed into a truncated load, which loads only a part of the variable from memory. For a 64-bit variable (in other words, long long) the truncated load will no longer result in an internal error.
[EW21517]
In EWARM 5.41.2:
Complex array index expressions in loops no longer result in an internal error.
[EW21545]
In EWARM 5.41.2:
Types smaller that 32 bits must sometimes be sign- or zero-extended before being compared (using for example CMP, TST, or TEQ). Sign- and zero-extends are now generated when needed also for cases when the result of bitwise and/xor operations are compared with zero (in other words, cases for which a TST or TEQ instruction is generated).
[EW21550]
In EWARM 5.41.2:
Correct values are now produced when the intrinsics __CLZ, __REV, or __REVSH are used with a constant argument.
[EW21561]

V5.40 2009-07-10

New features

None.

Program corrections

An if-then-else statement could be optimized into a question mark expression even at low optimization levels, which would make the debugger confused as to which is the current statement. The optimization has now been disabled at optimization levels 'low' and 'none'.
[EW20828]
The compiler no longer generates a message for the usage of long long in system headers even though the options --strict_ansi and --warnings_are_errors are used.
[EW20844]
The final value of variables in loops transformed into a memcpy or memset call could, in some cases, be off by one.
[EW20886]
Fixed an internal error in the compiler when trying to match an out-of-line template member function definition to the correct declaration. The problem occurred when two or more template member functions differed in the this qualifiers of a pointer to member function type parameter.
Example:
```
      struct X
      {
        template int fun(Y (Z::*fp)());
        template int fun(Y (Z::*fp)() const);
      };

      template
      int X::fun(Y (Z::*fp)())
      {
        return 1;
      }
```
[EW20920]
The MISRA C error Pm020 was incorrectly reported as a warning and the corresponding rule number was omitted from the error message.
[EW20925]
When compiling multiple input files (--mfc) in Embedded C++ mode, the compiler could get an internal error [assertion failed at: ".\src\parser\edg\lower_il.c", line 2484] in some circumstances.
[EW20927]
Loops where a global variable (g) just held a result (g passed no value between loop iterations) could in some cases be incorrectly optimized.
```
    for (...) {
       g = ...
       if (...) break;
       g = ...
    }
```
[EW20952]
The compiler and assembler produced object files where group section header table entries did not appear before the entries of all their members, as required by the ELF format.
[EW20988]
After a memcpy call, where a buffer (b) was assigned n characters from a string literal of length n (all characters except the zero termination), a b[n] = 0 assignment could erroneously be removed.
[EW20991]
Associative expressions containing both a division and a modulo operation could in some rare cases be incorrectly optimized.
[EW21010]
When compiling EEC++ for Thumb, a class that inherits from three or more classes where a virtual method has three or more arguments, one of the generated thunks was faulty (when compiling with multiple inheritance there is sometimes a need for a piece of code that adjusts the 'this' pointer. This piece of code is known as a 'thunk').
[EW21014]
For a struct x of 8 bytes or more, allocated as a register variable with two fields a and b, a simple if statement that can be reduced to a question mark expression (such as x.a < x.b ? x.a : x.b) could result in an internal error.
[EW21017, 21108]
Member accesses to auto structs assigned with memcpy could in some cases be incorrectly optimized.
[EW21020]
When compiling for VFP, a function call with a variable argument list where an argument passed on the stack is converted from double to int could result in an incorrect stack pointer value.
[EW21023]
When compiling with --legacy RVCT3.0 for Thumb mode, and a constant is shared between functions of the same compilation unit, the compiler could in some cases generate one of the functions in a segment part with two bytes alignment. Four bytes alignment is required in such cases to correctly resolve the R_ARM_THM_PC8 relocation.
[EW21031]
The code generator could fail to detect that an object had been placed with stricter alignment than required by the type. This would, in turn, cause the compiler to crash when the code generator at a later stage expected the higher alignment.
[EW21059]
When a switch statement inside a loop is generated as a table with negative offsets, the same register could be reused for two different purposes at table lookup.
[EW21100]
The compiler could terminate with an internal error in some cases involving enum types defined in a template class.
[EW21101, 21112]
When optimizing loops where the loop limit is the result of an expression involving possibly negative values in a bitwise AND operation, the compiler could in some cases erroneously conclude that the loop body would execute at least once and eliminate the test of the initial iterator value against the limit. The result of this is incorrect loop code for the case when the loop body should not be executed at all.
[EW21118,21120]
In EWARM 5.40.4:
The runtime library no longer assumes that unaligned access is supported in Cortex-M0 or Cortex-M1.
[EW21262]
In EWARM 5.40.4:
Scalar stack parameters smaller than 32-bit are now properly sign- or zero extended before the function is called.
[EW21271]
In EWARM 5.40.4:
Compilation of a file using either of the intrinsics __get_interrupt_state or __set_interrupt_state no longer results in an internal error.
[EW21272]
In EWARM 5.40.4:
MISRA C is now available in EWARM-CM.
[EW21324]
In EWARM 5.40.4:
The compiler now generates correct debug information for calls to C++ member functions defined in another module. The step into debugger command for such a call now works properly.
[EW21327]

V5.30 2009-01-23

New features

__task extended keyword
By default, functions save the contents of used preserved registers on the stack upon entry, and restore them at exit. Functions that are declared __task do not save all registers, and therefore require less stack space. This is typically used by realtime operating systems.

Program corrections

Creating a variable with a class/struct/union type with type errors in one or more of its fields could earlier result in an internal error. This has been corrected.
[EW20367]
In some unusual cases the compiler could terminate ungracefully. Ungraceful terminations are now prevented.
[EW20380]
Stack usage reported in the listfile is now again a safe approximation.
[EW20410]
In some cases two pre/post increment/decrements in two consecutive expressions could cause an internal error. This problem has been corrected.
[EW20419]
Irregular loops could in some rare cases be optimized incorrectly. This problem has been corrected.
[EW20428]
Specifying a designated initializer on a field inside more than one level of anonymous unions/structs could earlier cause an internal error in the compiler. This problem has been corrected.
[EW20439]
An inline-assembler operation can now correctly generate an error for absolute addressing in ELF.
[EW20489]
The compiler could fail when generating code for certain loop constructs. This has been corrected.
[EW20503]
In some cases an address expression inside two nested loops could use a variable before it had been assigned a value. This has been corrected.
[EW20531]
At medium optimization level (or higher) for Cortex-M3, compilation of certain combinations of the constant 256 and the question mark operator (a?b:c) could earlier result in an internal error with the message "illegal state". This has been corrected.
[EW20537]
Variables of small type (for example char) could earlier be incorrectly hoisted as a loop counter even though it might wrap. This has been corrected.
[EW20563]
A do loop copying consecutive shorts, integers, or long longs have now a correct byte count when translated into a memcpy call.
[EW20570]
Return value temporaries created for functions that use a return value pointer did not get marked as having had their address taken. This has been corrected.
[EW20572]
In some cases the code could be optimized incorrectly if pointers of different types were used to access the same memory address. This has been corrected.
[EW20581]
Certain operations (typically bit-wise) involving template static data members of integer type could cause an internal error when compiling template code. This has been corrected.
[EW20608]
A loop could in some cases be incorrectly optimized if it updated a global variable preceded by an indirect store of the same type as the global variable.
[EW20627]
The compiler no longer tries to put CPSIE/CPSID in an IT-block.
[EW20652]
The min and max templates should now be optimized correctly after function inlining.
[EW20654]
The compiler no longer crashes after issuing the error Pe020.
[EW20684]
The intrinsic function __set_CPSR() generated the wrong assembler instruction. This has been corrected.
[EWARM-268]

V5.20 2008-06-24

New features

Support for vector floating point (VFP) coprocessors.

Program corrections

The compiler no longer removes reads from uninitialized volatile auto variables from the code.
[EW19167]
A thunk with fall through is now padded properly whenever it is needed.
[EW19481]
Source lines after a #line directive are now included in compiler list files.
[EW19654]
The compiler can now handle segment/section names that are the same as assembler instruction names, register names, etc.
[EW19674]
Out-of-line definitions of member functions of a template class are now made properly tentative.
[EW19678]
Declaring a class-specific two-operand operator delete in a class template no longer causes the compiler to crash.
[EW19707]
The compiler no longer crashes after emitting an error indicating an extraneous typename keyword in a template.
[EW19796]
MISRA C rule 23 no longer gives an error for non code symbols.
[EW19802]
Realloc no longer leaves the heap in a broken state after a call that tries to allocate more memory than there is in the heap.
[EW19803]
The compiler no longer crashes when generating DWARF debug information for a class-external typedef of a class-scoped enum type with more than 9 constants.
[EW19820]
When performing memcpy in Cortex-M3 and the source and destination pointers have different alignments, the last 16 bytes are now copied also in cases where the size is:
size = 32 + ((4 -(DstPtr & 3)) & 3) + (y * 16); // y = 0, 1, 2 e.t.c. [EW19837]
Instruction scheduling will no longer lift pop of LR over a function/library call.
[EW19872]
A call to memmove with aligned parameters is no longer incorrectly transformed into __aeabi_memcpy4 instead of __aeabi_memmove4.
[EW19878]
Masking a long long value now works.
[EW19908]
A function call, where one parameter is a pointer to a signed integral type that is cast to a pointer to the unsigned type of the same size (or vice versa), no longer causes an internal error if the function call is inlined.
[EW19933]
Loops with an unsigned loop variable, going from 0 to 1, will no longer be optimized incorrectly.
[EW19973]
Constant tables layout generation for Thumb2 code has been adjusted.
[EW19984]
In some rare cases structure assignments, where the source was a indirection of a pre- or post-incremented pointer, could be optimized incorrectly. This has been corrected.
[EW20071]
Debug information for variables in high registers (r8-r14) in Thumb2 code has been improved.
[EW20098]
[EW20100]
Clustering now handles segment/section-located initialized variables.
[EW20149]
In some rare cases an optimization that temporarily hoisted a memory cell (i.e. a global variable or a structure member) to a register did not transform the code correctly and one or more uses could still refer to the memory cell. This has been corrected.
[EW20150]
Fall through from an arm function to a thumb function is no longer generated.
[EW20164]
Invalid instructions no longer generate internal errors.
[EW20199]
Tag_ABI_enum_size now reflects the real size of enum used.
[EW20203]

V5.11 2007-12-11

New features

Support for Cortex-M1 and Cortex-M3.

Program corrections

If the code generator failed to place a small object of aggregate type in registers, it could fail also when it tried to place the object on the stack instead. This happened if the alignment of the object did not match the size of the aggregate members, resulting in the wrong offsets being used for all members except those placed on alignment boundaries.
[EW19478]
A 32-bit mask operation with all except the highest bit together with a test on the highest bit of the same variable could generate incorrect code in Thumb mode.
[EW19480]
The section ".textrw" can now be renamed.
[EW19672]
The compiler can now handle segments/sections with names that are identical to names of assembler instructions, registers, etc.
[EW19674]
Out-of-line definitions of member functions of a template class were not made properly tentative, resulting in erroneous 'duplicate definition' errors when linking. This has been corrected.
[EW19678]
Declaring a class-specific two-operand operator delete in a class template no longer causes the compiler to crash.
[EW19707]
Bad syntax in function declarations no longer generate internal errors.
[EW19718]
Doubles are now rounded correctly.
[EW20026]

V5.10 2007-06-12

New features

Object files are now produced in the ELF/DWARF format.
Support for AEABI, which means interperability with other ARM EABI compliant tools.

Program corrections

The compiler now produces an error when an initializer for a static variable contains the address of a bitfield member.
[EW17962]
A function-like macro, named as a predefined IAR attribute name, no longer makes the compiler end erroneously.
[EW18386]
In rare cases, only the high part of a 64-bit variable was loaded.
[EW18735]
NOP instructions, inserted with the intrinsic function __no_operation() was scheduled causing them not to appear at the desired places in the code.
[EW18767]
The header file MtxWrapper.h now works from C++.
[EW18769]
Loops containing array accesses with index expressions of char type could earlier in some cases be optimized incorrectly.
[EW18815,EW18963]
Inconsistencies between several declarations or between declaration and definition of the same function now give proper diagnostics.
[EW18818]
The header file Dlib_Product.h is now compilable with MISRA C.
[EW18843]
Interweaved stores with zero and reads from the same structure could earlier be done in incorrect order.
[EW18845]
Wrong code was generated when passing an unaligned struct as parameter in big endian mode.
[EW18900]
swprintf and vswprintf now correctly handle the ending \0.
[EW18948]
In some rare cases, common subexpressions involving a struct pointer (p->x) was incorrectly optimized if the expression was preceded by an equality test between an other member in the same structure and a constant (p->y == 0).
[EW19015]
Functions with __irq and __fiq now save the vfp status register when compiling for vfp.
[EW19047]
The compiler no longer generates an erroneous constant for a compound literal that is used in a file-scoped initialization.
[EW19076]
swprintf now handles large strings correctly.
[EW19105]
Large functions could give the following internal error: Internal Error: [CoreUtil/General]: Jump distance to far for B.
[EW19179]
Clustering could cause zero initialized data to occupy ROM space, instead of using zero initialization.
[EW19232]
The ! operator on a byte in a char buffer (example: return !buf[0];) could earlier cause the internal error:
Const_Folding - Internal error Unequal types for operator != Internal Error: [CoreUtil/General]: Const_Folding - Internal error
[EW19337]

V4.41A 2006-12-08

Program corrections

The compiler generated misleading errors for unevaluated parts of constant expressions in some circumstances, for example:
const unsigned int z1d = ( (0) ? ( ( 1 >= (1ul << -6) ) ? 1 : 2 ): 1 );
This expression contains a negative shift count, which would normally result in a diagnostic, but the problem is in the non-evaluated part of the containing conditional expression, so this diagnostic is suppressed. The negative shift count makes the comparison undeterminate, which resulted in a "constant value is not known" diagnostic. This subsequent diagnostics was not suppressed, which it also should have been.
[EW18140]
In Thumb-mode a tail-call could incorrectly be optimized to jump even when the jump distance was just out of reach.
[EW18151]
A stack-backtrace information problem with __irq and __fiq functions has been corrected.
[EW18152]
Inverting a long long variable could earlier generate an internal error.
[EW18157]
Instruction scheduling could earlier incorrectly lose some debug information for inlined functions.
[EW18180]
A function containing a structure assignment inlined in a loop body could in some rare cases cause an internal error.
[EW18182]
The optimizer could incorrectly remove CMP instructions if the preceding arguments looked like constants.
[EW18231]
When a constant table was placed immediately after a switch table, a dangling (duplicate) label might be left which caused the backtrace analysis to abort the compilation with the following error message
```
   Internal error: [CoreUtil/General]: BtThreadAnalyzer:
   No direct arc from node to successor 
```
[EW18259]
If the compiler found several stores with zero to consecutive memory locations the last store could be done with wrong size.
[EW18273]
The compiler did not handle large functions properly in thumb mode.
[EW18276]
The <vector> header no longer relies on the undefined symbol TRUE
[EW18284]
Branch chaining optimization could incorrectly chain a BNE instruction via a BHI instruction.
[EW18312]
Variables declared both static and volatile were incorrectly not treated as such at all times.
[EW18316]
For a struct with short members, the members could incorrectly be written as a 32-bit entity when the short member was kept in register. This could also lead to adjacent members being overwritten.
[EW18320]
In some rare cases the intrinsic __no_operation() function could give an internal error message.
[EW18396]
Bitfield assignments should now work correctly, even when the function call on the right-hand side of the assignment modifies other bitfields in the word.
[EW18460]
In some rare cases, a series of assignments could be optimized incorrectly, for example assignments like:
```
x = ...;
y = x;
x = !z;
...
use(y);
```
[EW18540]
Using #pragma optimize to lower optimization level for a function no longer affect optimization of static accesses in other functions.
[EW18582]
An optimization can lift a global variable to a register in a code region. In some rare cases the register was not written back to the variable on all paths from the region.
[EW18814]

V4.40A 2006-06-03

Program corrections

In some rare cases, the optimizer incorrectly transformed a for or a while loop to a do loop if: the loop test compared the loop counter to a variable (V) that was invariant in the loop, and the loop was preceded by an if-else-if-statement where the else-if-test tested V against a constant value.
[EW17723]
High optimization could, in some rare cases, incorrectly hoist a common subexpression (1) across the initialization of another common subexpression (2) where (2) was the value of a global pointer variable and (2) appeared as a subexpression in (1).
[EW17754]
Saturate idiom was recognized even at low or no optimization making the code harder to debug.
[EW17802]
An ARM-mode peephole optimization could optimize a MUL + ADD to MLA even thou the ADD had a shifted operand.
[EW17833]
Functions with inline assembler with labels could incorrectly be inlined.
[EW17862]
Incorrect code could in some cases be generated in thumb mode for saturate idiom.
[EW17868]
Inlining of functions where a pointer parameter was declared volatile could in some case result in incorrect code.
[EW17902]
The result of the instruction scheduling could in some cases differ between compilations with same input.
[EW17919]
Functions that dereferenced a pointer after testing if it was NULL could be optimized incorrectly.
[EW18038]
Loops that added invariant expression to an indirection of an invariant pointer and the loop index variable (p[i] += 4711) could in some cases be optimized incorrectly.
[EW18089]
Unaligned store of zero could give internal error if neighbored with another zero store.
```
            char charr[100];

            *(int*)(&charr[1]) = 0;
            charr[5] = 0;
```
Note that this kind of code probably will not execute correctly, since most ARM architectures do not support unaligned accesses.
[EW18124]
New features
Support for the Cortex-M series has been added.
Output from the compiler is now in unified assembler syntax.

V4.31A 2006-02-03

Program corrections

Invariant assignments could in some cases incorrectly be hoisted out of for or while loops, if the loop test contained an || operator.
[EW16986]
High optimization could in some cases generate incorrect code for nested loops if the inner loop was not executed for every iteration of the outer loop.
[EW17010, EW17064]
The compiler could in some rare cases loop if the outcome of the condition in a conditional (? :) expression could be determined by assignments in the preceding basic blocks.
[EW17026]
Nested irq functions did not return properly.
[EW17032, EW17033, EW17038]
A char or short loop counter initialized with a function call could in some cases result in an internal error.
[EW17039, 17179]
Assignments to an auto array could incorrectly be removed as dead code if the only use of the array, besides assignments to it, was to assign the array address to a global pointer.
[EW17041]
Incorrect interpretation of the Z flag when analyzing a CMN instruction could lead to incorrect optimizations.
[EW17065]
Accessing a data member of a base class of a class object returned by value from a function call no longer results in an internal error.
Example: fun().x, where x is a data member of a base class of the type returned by fun().
[EW17085]
Optimization of a function tail call into a branch instruction in a thumb function that takes stack parameters generated wrong stack offset to the stack parameters.
[EW17117]
Delayed stack-cleaning in combination with stack access and a conditional (? :) expression could generate wrong stack offset.
[EW17127]
Loops where the loop counter was a short int or char could earlier result in incorrect code if the loop increment was negative and high speed optimization was used (-s9).
[EW17129, 17164]
When constructing a vector of POD data (data with no constructors) with an initial non-zero size, the elements are now correctly zero-initialized. For example:
```
      vector<int> v(3);
```
v should in this example contain 3 integers, each initialized to zero. Previously the integers were incorrectly left uninitialized.
[EW17160]
Code with both shifting and division by a constant value could in some rare cases generate internal error.
[EW17162]
Loops where the trip count was constant and the final statement was a switch expression could in some cases cause an internal error when high optimization was used.
[EW17181]

Incorrect code could be generated for small loops with descending access patterns. For example:

      for (i = 0 ; i < n; ++i)
        a[100 - i] = ...;

      for (i = 0 ; i < n; ++i)
        *(p-- + 17)= ...;

[EW17184]

The MISRA C rule 113 states that members of a structure or union shall only be accessed via their name. The compiler now diagnoses a violation of this rule correctly when a pointer to an element of a member array is created. For example:
```
      struct {
        int a;
        int b[2];
      } x;

      x.a;    /* Was diagnosed     */
      x.b[0]; /* Was not diagnosed */
```
[EW17186]
An __swi declared function pointer now correctly gives an error message.
[EW17329]
A register transfer instruction were in some cases optimized away due to incorrect optimizer analysis of sign extend operations.
[EW17330]
Incorrect code was generated for assignments of instances of vector<> in two cases:
1. The assignment of a vector where the elements could use bitwise copy and where the destination vector was smaller than the source vector but had a capacity that was large enough.
2. The assignment of a vector where the elements needed copying or construction using member functions but did not need destruction, where the destination vector was larger than the source vector.
These assignments now work correctly.
[EW17413]
R8_fiq - R12_fiq was unnecessarily saved when entering an fiq exception.
[EW17453]
The internal error: [Ect]: Optimize has been corrected.
[EW17461]
An error message is now given if the --segment option is used more than once with the same segment specifier.
[EW17463]
On high optimization, array initializations and assignments to array members could be incorrectly removed as dead code if the only explicit use of the array was to assign its address to a member in a packed struct.
[EW17466]
A problem in the instruction scheduling optimizer has been corrected. A pop instruction to restore callee saved registers could be hoisted over an instruction that defined one of theses registers.
[EW17495]
When compiling for interwork, a redundant mode change entry will be inserted in front of a generated function. This function may save information about code size if the function is called from code with different mode (arm/thumb). In some cases the compiler missed to generate this mode change entry. The generated code is still correct but can give different code size between compilations.
[EW17603]
New features
The command-line option --no_path_in_file_macros has been added. It removes the path leaving only the filename for the symbols __FILE__ and __BASE_FILE__.

V4.30A 2005-06-23

Program corrections

Warning Pa084 ("pointless integer comparison with out of range value") will no longer be issued erroneously in cases where a relational operator is used with a template non-type parameter of integer type.
[EW16367]
Some float NaN patterns were not correctly converted to double.
[EW16373]
Using compound literals, a C99 feature, could result in an internal error in the compiler.
[EW16412]
Inline assembler code with illegal instructions like MOV R0,@R1 could generate an internal error
[EW16414]
An inline-assembler statement containing nothing but a newline character could cause an internal error in the compiler. Example: asm("\n");
[EW16415]
A label placed on the first line of a multi-line inline-assembler statement could cause errors.
Example:
```
   asm("loop:\n"
       " bra loop"); 
```
[EW16417]

Loops with multiple assignments to an auto variable could result in incorrect code, when the loop also contained partial accesses (with a non-zero offset) to the auto variable.

void ByteSwap128(short *addr)
{
  int i;
  short tmp;
  char *dst, *src = (char *)&tmp;
  for (i = 0; i < 64; ++i)  
  {    
    tmp = *addr;
    dst = (char *)addr++;
    dst[0] = src[1]; /* points to (char *)&tmp + 1*/
    dst[1] = src[0];

    tmp = *addr;
    dst = (char *)addr++;
    dst[0] = src[1];
    dst[1] = src[0];
  }
}

[EW16419]

The compiler now generates the same alignment for the following two definitions:
unsigned char a [6] = {0,0,0,0,0,0};
unsigned char b [] = {0,0,0,0,0,0};
[EW16430]
Loops with a non-constant trip count (number of iterations in the loop) could be uncorrectly unrolled.
[EW16439]
Common subexpression elimination no longer hoists expressions that incorrectly can cause an exception, unless the expression is guaranteed to be executed in all successors.
[EW16443]
Fixed a problem were iswprint erroneously returned true for the characters carriage return and newline.
[EW16465]
Branch-chaining optimization, which is performed at the highest size optimization level, could incorrectly chain a BCS instruction via a BHI instruction. This could cause a branch to go the wrong way at runtime depending on the status of the Z-flag.
[EW16481]
An expression containing the new operator could generate a reference to the wrong constructor when an optimization level of 6 or higher was used, at least one of the parameters to the constructor was an object passed by copy construction, and the constructor definition was not visible in the same compilation unit as the expression containing the new operator.
Example:
```
struct X
{
  X(X const &);
  ...   
};
   
struct Y
{  
  Y(X);
  ...
};

Y * mkY(int a) { return new Y(a); }
```
If the function mkY was not in the same file as the definition of Y::Y(X), a reference was created to Y::new Y(X *) instead of to Y::new Y(X).
[EW16482]
Calculating remainder by a constant could give the wrong result at the highest speed optimization level.
[EW16487]
Overlapping stores with zero could caused an exception in the compiler at high optimizations. The compiler analyzes stores with zero to memory and optimizes them. If there were instructions that wrote to overlapping memory locations, the compiler could terminate with the following internal error:
```
      Internal error: [Ect]: Any exception
      Fatal error detected, aborting.
      Internal error: [PostOptimize]: Any exception
      Fatal error detected, aborting.
```
[EW16489,EW16491]
Optimizer inlining failed to recognize the #pragma location directive, leading to located code being placed in the wrong segment.
[EW16529]
The compiler could generate incorrect code if:
1. A function (f) assigned a variable (p) to point to an object (o) and returned the variable p,
2. the function result was assigned to a variable (q) of the same type as p,
3. the object o was modified before an access to o through q
4. and the function call to f was inlined by the optimizer.
[EW16537]
An optimization that tries to hold a global variable in a register during several modifications of the global variable could in some cases cause incorrect code.
[EW16547]
In some cases, a loop with an upper bound that was a signed non-trivial expression divided by a power of two could result in incorrect code.
[EW16550]
Complex ?: sequences could cause an internal error at the high optimization level.
[EW16552]
When compiling EC++, constant variables initialized with simple floating point expressions were put in RAM memory instead of ROM memory.
[EW16587]
Corrected an internal error that could occur when an assignment to an auto structure contained a reference to a member in itself or another auto structure.
```
struct X x, y, *array;
x = array[x.m];
```
[EW16606,EW16608,EW16627,EW17177]
A Thumb MOV immediate to low register could be hoisted in between a CMP-BCC/BCS sequence, which destroyed the effect of the CMP instruction.
[EW16611]
In some rare cases, values were not written to memory before a function call.
[EW16620]
Code that implements a saturate operation (keep a value inside a range such as -128 to 127) could produce incorrect code in both Thumb and Arm mode.
[EW16626,EW16670]
At the high optimization level incorrect code could be generated if a loop had an unsigned loop counter, the loop counter was decremented, and the loop contained a test (besides the loop exit test) where the loop counter was compared to zero.
[EW16646]
An internal error in constant table generation for functions that end with a fall through to the common exit sequence has been corrected.
[EW16657]
Incorrect code could be produced when a "Rn <shift> Rm" operand is spilled to other registers and there is an overlap between one of the original registers and the new destination. The error occurred because the operand was not properly reconstructed to reflect the new registers that the values were moved to.
[EW16671]
Optimizer inlining failed to recognize __ramfunc, leading to that code meant to be placed in RAM could end up in ROM.
[EW16698]
If both statements in an if else statement are identical (after removal of dead code) an optimization that merges the two statements could in some cases also remove side effects (for example calls or volatile accesses) in the redundant condition.
[EW16735]
Incorrect code could be generated when the initial value for a signed loop counter was computed with an & expression where both operands where non-constant expressions.
[EW16757]
Two STRB with zero to offset 256 and 257 could be compiled into a single STRH which then had its offset truncated to 0.
[EW16885]
Coprocessor instructions MCR and MRC are no longer moved around by the instruction scheduler. They previously were allowed to be move past a volatile side effect.
[EW16886]
If a loop with a variable upper limit was preceded by a modification of the upper limit and a test of the upper limit being larger than the lower limit of the loop, the optimizer could incorrectly assume the loop body should always be entered.
```
    if (u > 0)
      {
        --u;
       for (i = 0; i < u; ++i)
        {
          ...
        }
     }
```
[EW16887]
Including an I/O definition header and referencing more than one SFR from C++ code will no longer result in incorrect "more than one definition for struct/union type" warnings when linking.
[EW16957]
Unrolling of loop with non-constant trip count could cause internal error in the optimizer.
[EW17006]
New features
Support for ARM11 and V6 has been added.
The execution speed of the floating point library has been significantly improved.
Code size and speed performance have been improved for both ARM and Thumb.
It is now possible to declare variables in the initialization clause of a for statement, but only in extended language mode. This behavior is according to the C99 and the C++ standards.
You can now compile several source files in one compilation by specifying the command line option --mfc. The advantage of multi-file compilation is that it gives the interprocedural optimizations a larger set of functions to work on. If you also specify the command line option --discard_unused_publics, the optimization will be further improved because the compiler will assume that there are no references to any symbol from the outside in the compilation, i.e. the compilation unit is the whole application apart from the library.
Use the --mfc option with caution, because it is experimental in this version of the compiler.
Some more C99 functionality has been added to the IAR DLIB Library:
- Ctype.h defines isblank as an added function.
- Inttypes.h has been added. Note that only the conversions are included, not the functions.
- Math.h defines the following additions:
  Macros - HUGE_VALF, HUGE_VALL, INFINITY, NAN, FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, FP_ZERO, MATH_ERRNO, MATH_ERREXCEPT, math_errhandling.
  Typedefs - float_t, double_t.
  Macro functions - fpclassify, signbit, isfinite, isinf, isnan, isnormal, isgreater, isless, islessequal, islessgreater, isunordered.
- Stdlib.h defines llabs, lldiv, strtoll, strtoull, atoll, strtof, and strtold as added functions.
- Wchar.h defines vfwscanf, vswscanf, vwscanf, wcstof, and wcstolb as added functions.
- Wctype.h defines iswblank as an added function.

V4.20A 2005-01-10

Program corrections

Using #pragma vector on an interrupt function did not update the exception vector table.
[EW14086]
A function definition at a line number greater than 65535 could cause an internal error, due to an unused line number field in an object file record that overflowed.
[EW15542]
Call to an __irq or __fiq function could generate an internal error.
[EW15561]
__ramfunc functions shared relay functions with non __ramfunc functions in the same module. If they were placed far from each other that could generate a link error.
[EW15562]
The scheduler failed to recognize overlapping load and store operations if they were of different size.
[EW15579, EW15656]
A volatile load directly following a store to the exact same location could reuse the stored value instead of loading it again.
[EW15582, EW15657, EW15663]
A declaration of a block local variable with no initialization, immediately followed by a label, resulted in incorrect code in some cases.
[EW15594]
In some cases auto-variables of union type were optimized incorrectly. Assignments to a member (m) were incorrectly removed if the union definition contained a declaration of another member, of equal or larger size, below the declaration of m.
[EW15595]
The scheduler could generate an internal error for a large basic block without any statement info.
[EW15596]
If a function had multiple return statements and all returns were preceded by an assignment to the same global variable (or an indirect assignment using the same pointer), the return value could be overwritten by a temporary value.
[EW15600]
Some caller-saved registers were not saved when calling library routines for floating point subtraction and division.
[EW15601]
Fall through to a large 'common exit sequence' with several constant references could generate constant entries out of bounds.
[EW15613]
AND with a constant that was converted to BIC on a variable smaller than 32 bits could leave garbage in the higher bits of the register.
[EW15621]
In some cases auto-variables of structure type caused an internal error if the structure had a member of union type.
[EW15622]
A register parameter could in rare circumstances be allocated in the same register (or overlapping register) as another local variable.
[EW15623]
Hoisting of loop-invariant code could in some rare cases generate incorrect code.
[EW15624]
Code optimized to a conditional tail jump could generate an internal error.
[EW15625]
A basic block could in some cases be flattened even if it had multiple predecessors with different flags set.
[EW15627, EW15768]
FLDS, FLDD, FSTS and FSTD can now have relocatable offset. This is needed when accessing constants from vfp code.
[EW15641]
Constant entries could in some cases, especially large long long switches, be placed among the switch data. This could lead to random jumps anywhere in memory.
[EW15643,EW15660,EW15661,EW15665]
Invariant definitions were in some cases hoisted even if it defined alive non-invariant resources or used a non-invariant resource.
[EW15646]
Offset check for constants placed in another segment part was too pessimistic. This could lead to internal error.
[EW15653,EW15654]
In some rare cases the compiler performed incorrect optimizations (for example constant propagation or common subexpression elimination) of accesses through pointers. The effects were noticeable when the same data object was accessed through different pointers. The problem was unlikely to occur in non-trivial functions.
[EW15655]
long long switch in thumb mode could generate unaligned accesses.
[EW15659]
In some cases the compiler tried to flatten a basic block ending with a table switch. This generated broken code.
[EW15664]
In some cases union accesses were optimized incorrectly. The union accesses could only have two sizes and one of the sizes must be the whole union. Accesses of the two differing sizes must be interleaved so the contents of the union was read with a different size than the value stored in the union.
[EW15681]
The intrinsic __no_operation() could be optimized away in Arm mode.
[EW15690]
When a volatile-declared variable was used in the index expression of a volatile-declared array expression, the compiler issued an incorrect warning about undefined order of volatile accesses.
[EW15710]
The #pragma vector was broken in several ways.
1. The segment part was generated as noroot causing the linker to remove it.
2. Multiple vector numbers was not recognized.
3. The vector number was scaled wrongly.
[EW15781]
When typedefs were involved in an integer comparison, the compiler sometimes incorrectly issued the warning Pa084 (pointless integer comparison with out of range value) for cases where such a warning was inappropriate.
[EW15793]
Swi vector for declared only functions was sometimes treated as 0.
[EW15862]
A thumb peephole pattern which propagates an ADD instruction beyond a LDR/STR instruction by modifying the addressing mode of the LDR/STR instruction did not take care of all situations properly with respect to flags being alive after the instruction.
[EW15898, EW16191]
The compiler could generate wrong debug information for local variables causing them to be shown as unavailable in the debugger watch window.
[EW15948]
Complex expressions containing a signed division with a constant denominator could in some cases cause an internal error.
[EW16000]
Evaluation of expressions with the %= operator now follows the rules for integral promotion.
[EW16001]
The internal header file xlocale.h did not work properly when the current locale was the C locale (which it typically is) and the symbol C was defined as a preprocessor macro.
[EW15602]
The use of a variable (x) could incorrectly be eliminated from an expression, if 1. the expression contained both a use and a defining use of x and 2. the expression contained a use of another variable (b) that was the single use of it 3. no defining use of x occured before b's defining use
```
      void use(int);
      int broken(void)
      {
        int x; /* x uninitialized */
        int a = 1;
        int b = 2; /* b's definition */

        x = a; /* this defining use of x is overlooked */
        use(x);
        x = b + x; /* use and def of x, use of b */
        use(x);

        return x;
      }
```
[EW16002]
The compiler now attempts to warn about undefined behavior in some situations involving sequencing or multiple modifications with no intervening sequence point. If this warning involved data accessed through the implicit this pointer of a C++ member function, an internal error resulted.
[EW16021]
The scheduler could rearrange code including a constant load to VFP register even when conflicts would appear.
[EW16051]
An initialized auto array inside a loop no longer causes an internal error.
[EW16052]
Relay function to div/mod trashed R2 in thumb mode. Such relay functions is needed when the distance between the caller and the callee is more than 4 Mbytes.
[EW16061]
A problem where using the preprocessing operator define could cause an internal error has been corrected.
[EW16076]
Register allocation of VFP registers could differ between compilations of a specific source code depending on Windows memory allocation. The code produced was correct, but not necessarily identical.
[EW16083]
Long functions can make use of spring board jumping which utilize existing jumps to avoid generating a long branch, by forming branch chains. In one rare case a conditional branch immediately preceeding the destination label could incorrectly be incorporated in such sequence (its destination points elsewhere, but it has fall-through flow to the target label).
[EW16097]
Defining a C preprocessor macro with the same name as any directory component of the library configuration file path would change that component giving the wrong path.
[EW16220]
long long operations such as add, subtract, negate could be incorrectly made if the low part of the result overlapped with the upper part of one of the operands. This happened in some rare situations when the register pressure was high.
[EW16331]
8-bytes stack alignment was not always preserved.
[EW16332]
Complex pointer to data member access could generate internal error with bad data alignment.
[EW16370]
The compiler could terminate with
Internal Error: [CoreUtil/General]: Const_Folding
when doing a cast on pointer arithmetics.
[EW16898]
The common subexpression elimination optimization could could give different (but correct) output depending on compilation environment, producing slightly different (but correct) code between compilations.
[EW17918]
New features
A new object attribute, __noreturn has been added. The attribute can be used on functions to inform the compiler that the function will not return. The compiler can then generate more efficient code. Examples of functions that do not return are abort() and exit().
To determine the configuration file for DLIB from the command line, use the compiler option --dlib_config config_file. The old variant, using -D_DLIB_CONFIG_FILE=config_file, will still work but can interfere with other preprocessor defines.
Support for compound literals has been added to the C language.
New compiler command line option --preinclude include_file.
The inline assembler operator asm() now supports multiple instructions and local labels. Example
```
      asm("Loop:  MOV R0,#10     \n"
          "       ADD R3,R3,R2   \n"
          "       SUB R0,r0,#1   \n"
          "       BNE Loop");
```
Note that the instruction separator is '\n' and that the definition and the reference of a local label do not necessarily need to be in one asm().

V4.11A 2004-06-10

The following C99 features can now be used in the C language if language extensions (-e) are enabled:
- The inline keyword. It works as the C++ inline keyword (and the #pragma inline declaration).
- Mixing declarations and statements within the same scope.
- Having a declaration in the initialization expression of a for-loop.
The standard library fopen() function incorrectly worked and returned a valid file pointer, even when not linking the application with the debug information without I/O emulation modules, available by choosing Project Options and selecting the Linker category.
[EW13922]
In rare cases at high optimization levels, the optimizer data flow analysis could fail with an internal error.
[EW15026]
The namespace scope of extern "C" functions was incorrectly included in their linker visible names, which sometimes could lead to incorrect Undefined External errors when linking.
[EW15088]
Instruction scheduling could in some cases change the order of two volatile read accesses.
[EW15119]

In some cases an array element reference could be optimized incorrectly if the address was computed in two separate expressions and both contained the loop counter. For example.

  int a[100][100];
  int foo()
  {
    int i;
    for (i = 0; i < 10; ++i)
    {
      int *p = &a[i][0];     /* first use of i */
      p[i * 2] = 4711;       /* second use of i */
    }
  }

[EW15123]

If all paths to a switch statement with a single variable as a switch expression contained assignments to the variable, it could in some rare cases cause the compiler to loop when all the jumps to the switch were redirected to their destination into the switch body.
[EW15131]
Functions declared __swi and with calls to other functions could generate an internal error.
[EW15327]
The va_start1() intrinsic function incorrectly gave a warning when the option require_prototypes was used.
[EW15328]
Switch on character expression with all case values between 0x80 and 0xFF could generate incorrect code.
[EW15349]
Too agressive optimization could incorrectly casuse a needed AND instruction to be removed.
[EW15396]
The treatment of the #pragma segment directive has been changed to allow multiple equivalent declarations of the same segment.
[EW15413]
A switch statement with case values in a range greater than 255 could generate an internal error.
[EW15462]
The compiler printed diagnostic text contained the obsolete segment types HUGEDATA and HUGECONST instead of DATA and CONST.
[EW15464]
Library call from located functions could incorrectly cause reference to undefined symbol.
[EW15465]
A function with a parameter of type pointer to class could sometimes get an incorrect name in the object file, resulting in an 'undefined external' error when linking. For this to happen, the class must have a user-defined or non-bitwise compiler generated copy constructor, and there must be a definition of another function in the same module returning the class by value. That function must, apart from the pointer to class parameter, be declared with the same parameter types as the first function.
[EW15466]
An ARM function compiled for VFP with an integer parameter located in register and later stored on the stack could generate an internal error.
[EW15469]
No relay function was generated for calls to __ramfunc functions declared in the same module even though the distance was too far for the BL instruction.
[EW15485]
The shift count was not properly zero extended for long long shifts.
[EW15500]
If a register was used in a loop only by a single instruction, that register could incorrectly be considered as dead after the refering instruction.
[EW15612]

V4.10B 2004-03-09

Two new intrinsic functions are now available in the compiler, __MCR() and __MRC(). They make it possible to access coprocessor registers from C and C++, and not just from assembler language. __MCR() inserts a coprocessor write instruction, MCR, and __MRC() inserts a coprocessor read instruction, MRC. For syntax details, please see the inarm.h header file.
A new compiler command line option, --separate_cluster_for_initialized_variables, has been added to separate initialized and uninitialized variables, when using variable clustering. The use of this option can make the *_ID segments smaller at the expense of code size. Variable clustering is disabled altogether by the --no_clustering command line option.
A new compiler keyword, __nested is available to allow nested interrupts. The keyword modifies the enter and exit code of an interrupt function to allow interrupts to be enabled and to be served inside the interrupt function without overwriting the SPSR and return address in R14. Nested interrupts are only supported for __irq functions. For example:
```
  __irq __nested __arm void interrupt_handler(void);
```
Some ISO C99 features have been added. They are available when language extensions are enabled.
- Support for the bool data type, if the header file stdbool.h has been included.
- _Pragma support. This operator works as the pragma directive and can be used in macro definitions.
- Variadic macro support. You can now write printf-style macros.
- Hexadecimal floating point constants support. This means the ability to exactly specify a floating point constant. The functions strtod(), printf(), and scanf() recognize the syntax.
- The macro definition __func__. If used in a function, it is defined to the name of the function.
- Designated initializers. Using these, you can initialize a specific element in a structure or a specific element in an array.
- Inline functions. The pragma directive inline[=forced] has been added as well.
- long long support in the library. For example the functions strtoll(), strtoull() have been added as well as support for them in printf() and scanf().
The localtime C++ runtime library function generates negative values for the tm_mday element.
[EW12510]
The compiler could generate an internal error when performing live-dead analysis on a data pointer that was casted from a function pointer. The problem was present on optimization levels medium (-z6/-s6) and high (-z9/-s9).
[EW14949]

No relay is generated in the following code (The compiler does not know how far apart these two functions actually are...)

  #pragma location="CALLEE"
  __thumb void callee()
  {
	  volatile int a = 0;
  }

  #pragma location="CALLER"
  __thumb void main()
  {
	  volatile int a;
	  callee();
	  a=1;
  }

[EW14973]

In the following code the relay for the call from caller() to callee() will be 'knocked out' by the relay entry to callee.
```
  #pragma location="CALLEE"
  __thumb __interwork void callee()
  {
	  volatile int a = 0;
  }
```
[EW14975]
In a member function of a template class or one of its nested classes, a delete expression involving a pointer to one of these classes could cause an internal error when compiling.
[EW14979]
When compiling C++ code, the compiler could fail with an internal error when the result of a struct/class/union assignment was used (for instance in a chained assignment expression), the struct/class/union had no user-written assignment operator, and the assignment could be performed as a bitwise assignment.
[EW14981]

The body of the following loop was incorrectly treated as invariant.

  struct
  {
    int x;
    int array[10];
  } s;

  void f(void);
  void g(void);

  void test()
  {
    int i;

    for(i = 0; i < 8; ++i)
    {
      if (s.array[i])
      {
        f();
        return;
      }
    }
    g();
  }

[EW14985]

When an inline member function was called from an __arm function, instead of calling the member function the object's destructor was called.
[EW15102]
When an inline member function is called from an __arm function, instead of calling the member function the object's destructor was called.
[EW15103]

V4.10A 2004-02-21

Valid stack backtrace information is now available in the IAR C-SPY Debugger inside the __irq and __fiq interrupt functions.
[EW12251]
Variables initialized to zero, either by explicitly setting them to zero in the code or as default behavior when no value is given, were cleared to zero by cstartup. A very small table entry was used to describe an entire block of memory to be cleared. If such zero-initialized variables are clustered together with variables that have explicit non-zero initializers, they would get explicit zero bytes to be copied by cstartup. If the zero-initialized variable was large (an array, for example), this could result in a waste of read-only memory. There is a new option that can be used to correct the described behavior:
--separate_cluster_for_initialized_variables
Separate initialized and uninitialized variables, when using variable clustering.
[EW12980]
The stdout stream is now buffered. Unbuffered stdio could cause slow terminal I/O performance in the debugger.
[EW13609]
Assignments of derived class objects to base class variables (also known as "slicing" assignments) where the assignment could be performed by bitwise copying caused an internal error when compiling.
[EW14094]
Some syntax errors could cause a subsequent internal error when the --require_prototypes option was used.
[EW14107]
When generating a constructor or destructor for an unnamed structure or class (for example, because one of its members had a constructor or destructor) an internal error occurred.
[EW14149]
An internal error was generated for a switch case value which was out of range for the switch type.
[EW14304]
The compiler sometimes generated incorrect code when dividing with, and comparing with -1 in a single statement.
[EW14344]
In some cases loops with long long loop counters could be optimized incorrectly.
[EW14345]
Incorrect code is no longer generated for long long decrements.
[EW14347]
Fix of several problems regarding bitfields in long long base types.
[EW14357, EW14361, EW14362, EW14366, EW14378]
An internal error with the message "Jump distance too far for B" could occur in some rare situations.
[EW14358]
Casting between float and the long long signed and unsigned types failed in Thumb mode when using the software floating-point runtime library. The library functions handling the casts used a return sequence that was not compatible with the v4 instruction set. Therefore, the Thumb state was not preserved by these casting operations.
[EW14365]
Side effects of function calls was not correctly handled for global bit fields.
[EW14367]
The intrinsic function __QFlag(), which is declared in inarm.h, is now correctly acknowledged as an intrinsic function by the compiler.
[EW14405]
All functions (including, but not limited to, all relay functions) are now KEEP_WITH_NEXT instead of REORDER. This prevents them from being reordered at link time, if packed placement (-P) is used. This is only an issue for applications larger than 4 Mbyte.
[EW14454]
Float comparison could result in an internal error at the highest optimization level when using the vector floating-point (VFP) unit.
[EW14669]
Compares with 0.0 when generating code for VFP was sometimes done as if the hardware supportes subnurmal-numbers.
[EW14670]
Template functions and member functions of class templates that were not inline (implicitly or explicitly) could cause an internal error in the compiler.
[EW14680]
The intrinsic function __CLZ() gave an internal error when compiled at optimization levels above 3.
[EW14723]
The extra 'new constructor'/'delete destructor' routines generated by the compiler when optimizing for space should be marked as tentative if the class involved is a template class, even if the corresponding constructor/destructor is not tentative. The compiler failed to do this, which could result in multiply defined symbol errors when linking.
[EW14746]
In some cases an assignment to a member in a structure variable could be erroneously eliminated, if the member was assigned a variable and that variable was assigned in all basic blocks preceding the basic block containing the structure variable declaration.
[EW14760]
Optimization no longer treats ~(x - y) as -(x - y).
[EW14788]
Printf format string characters above 0x7F were not handled correctly.
[EW14897]
When trying to avoid unnecessary setting of the vtable pointer in the constructor for abstract classes, if the class has a member variable that is an array of objects requiring construction, the compiler could hit an assertion in the internal file lower_init.c.
[EW14909]
When generating a constructor or destructor for an unnamed structure or class (for example, because one of its members had a constructor or destructor) an internal error occurred.
[EW14911]
Converting numbers using wcstoul() with more than 9 decimal digits gave the wrong result.
[EW14921]
The extra 'new constructor'/'delete destructor' routines generated by the compiler when optimizing for space should be marked as tentative if the class involved is a template class, even if the corresponding constructor/destructor is not tentative. The compiler failed to do this, which could result in multiply defined symbol errors when linking.
[EW14931]
A structure that only containes small integral types plus another structure of small integral types generated 32-bit LDR/STR instructions when operating on non-aligned data objects.
[EW15593]
In some situations the access to a variable could be hoisted above an assignment to that variable.
[EW16828]

V3.40C 2003-12-12

ELF/DWARF debug information for variables located in VFP double registers could not be handled by the linker. A linker internal error was generated.
[EW14206]
In some cases expressions containing a negation could cause an internal error if the expression below the negation was an associative and commutative expression with several constants.
For example certain expressions with succeeding minus signs, as in -(108000000-(temp-108000000)).
[EW14293, EW14532]
Missing intrinsic function declarations of __get_CPSR() and __set_CPSR() have been added to the inarm.h header file.
[EW14300]
In some cases loops with long long loop counters were optimized incorrectly.
[EW14345]
If a function that was compiled as __monitor __thumb __interwork did not destroy any registers that had to be restored, for example if the function body was empty, an internal error was generated.
[EW14445]
Some standard I/O library functions was linked into the application even if not used.
[EW14465]
When common sub-expression elimination (CSE) was enabled in the compiler optimizer, some constructs were previously optimized incorrectly. An example of such a statement is:
k = i + j + k;
[EW14497]

V3.40B-P1 2003-10-06

Compiling with VFP enabled in ARM mode, and declaring a function with __thumb in the same translation unit, could cause an internal error at optimization levels above 3.
[EW14210, EW14211]
The runtime library routine ??div8_a has been corrected so that it now makes a full 32-bit sign-extension of the divisor and dividend, as opposed to a 16-bit one, prior to performing the actual division operation. The previous behavior was not a bug according to the C standard, but it could unnecessarily lead to an "undesired" result.
[EW14239]
The result from signed 8- and 16-bit divide and modulo operations is now (correctly) sign extended.
[EW14298]
Optimizations based on register content tracking did not function correctly for multidimensional arrays. This could result in incorrect optimization of an access to an element in a multidimensional array, if two or more paths through the function could reach the access and at least one of the paths contained an assignment to the same element. Single dimensional arrays could also be affected if they were clustered. This problem only occured on optimization levels above 3.
[EW14342, EW14354]
Structures small enough to fit within a register could in some cases be read with incorrect alignment, that is with a single large read instruction instead of several small ones. This resulted in an undefined behavior.
[EW14353]
The expression X-(Y*Z) was incorrectly coded as FMSC[S|D] instead of FNMAC[S|D] when using VFP. Since this type of expressions are present in the sourcecode for sin(), cos(), and cosh(), applications using these library functions were affected.
[EW14359, EW14373, EW14389]
VFP function pointers were previously not recognized as the default function type.
[EW14360]
Using VFP and casting a float to an unsigned int or long could give the wrong rounding mode depending on the rounding mode set in FPSCR. Previously, the FTOUIS instruction was used, but the rounding mode of FTOUIS depends on FPSCR and gives the wrong result unless round towards zero is set in FPSCR. Now, the FTOUIZS instruction is correctly used instead.
[EW14363]
Using VFP and casting a double to a signed int or long could give the wrong rounding mode depending on the rounding mode set in FPSCR. Previously, the FTOSID instruction was used, but the rounding mode of FTOSID depends on FPSCR and gives the wrong result unless round towards zero is set in FPSCR. Now, the FTOSIZD instruction is correctly used instead.
[EW14364]

V3.40A 2003-07-03

Compiler assembly output in interwork mode could fail to assemble.
[EW13604]
A loop containing a condition, where a loop counter was multiplied with a value greater than 1 and compared to a constant, could, if certain additional conditions were met, be optimized incorrectly due to rounding errors when loop-peeling optimizations were performed. For example:
```
  int i, res;
  for (i = 0; i < 3; i++)
  {
    if((i * 2) < 1)
      res = 0;
    else
      res = 1;
    printf("i=[%d]:res=[%d]\n", i, res);
  }
```
Loop-peeling optimizations are only attempted when there is a maximum of three basic blocks within the loop and the highest optimization level (-z9/-s9) is used.
[EW13695]
When using Thumb mode and a long long, or a value whose temporary internal representation was long long, was part of a struct and located at an offset of 124 (bytes) within the struct, the compiler sometimes tried to generate syntactically illegal code. As a result, an internal error was generated.
[EW13702]
The global optimizer could in very special cases lose track of a temporary result.
[EW13925]
In some rare cases, the global optimizer could make incorrect assumptions of the contents of a clustered variable, b, inside a loop. Incorrect code was generated in these cases. For this to occur, the loop must reside within an if-else statement, it cannot change b but must change another variable in the same cluster, and b must be assigned in the other clause of the if-else statement. For example:
```
  int a;
  int b;

  void f(void)
  {
    if(a < b + 2)
    {
      while(a + b <= 0)
      a++;
    }
    else
    {
      b = b + 2;
    }
  }
```
[EW13936]
In some cases, inner loops could be optimized incorrectly if the trip count depended on the loop counter in a surrounding loop, the surrounding loop had a trip count of 2, and the loop counter in the surrounding loop counted down.
[EW13937]
In some cases, nested loops could be optimized incorrectly if the exit test in the inner loop jumped directly to the test in the outer loop. For example:
```
  x = ...;
  while (--x > 0)
  {
    y = ...;
    while (--y > 0)
    {
      ...
    }
    /* no code from outer loop here */
  }
```
[EW13942]
When SFB or SFE directives were used on segments containing tentative segment parts (PUBWEAK symbols), one such tentative segment part was used in the calculation of SFB/SFE, and the chosen definition of the segment part was located in a different segment than the tentative one, XLINK could generate the wrong value for the SFB/SFE.
[EW13972]
The compiler could produce different object code depending on the execution environment, such as the host operating system used. However, the generated code was correct in all cases.
[EW14003]
Signed compare on long long was previously performed incorrectly. The generated code performed an all-signed compare, when it should have done a signed compare on the high 32-bit word and an unsigned compare on the lower part.
[EW14020]
The sign-on message for the --segment command line option has been corrected. The sign-on message is displayed when invoking the compiler from the command line by typing "iccarm" only.
[EW14044]
Const objects which are located at an absolute address, and either implicitly initialized to zero or explicitly initialized to any value, were previously incorrectly placed together with located no_init (const and non-const) objects in the HUGE_AN segment. Now, they are correctly placed in the HUGE_AC segment.
[EW14050]
In some cases volatile global variables could lose the volatile attribute if they were clustered. Clustering was performed on high optimization level (-z9/-s9) only. For example:
```
  int y;
  int z;
  int volatile x;

  void f(void)
  {
    x = y;
    x = z;
  }
```
[EW14051]
All printf formatters, such as %d and %s, gave an incorrect output when the _Printf_small formatter was used.
[EW14068]
The following example previously generated Thumb ADD and SUB instructions in ARM mode, which resulted in an internal error.
```
  char x[8];
  void foo(void)
  {
    *(int*)&x[1] = 1;
  }
```
[EW14070]
An internal error could be generated when compiling Thumb code containing certain forms of 32-bit integer multiplications.
[EW14093]
A loop containing a condition, where a scaled loop counter was compared to a constant, could be optimized incorrectly if the test was for (non-)equality and the value was reached during the final iteration through the loop.
[EW14096]
Signed long long division with negative numbers gave wrong sign on quotient and remainder.
[EW14117]
Long long arithmetic right shift failed if high word was all ones.
[EW14118]
Alignment of complex objects like character arrays is now set to 4. The previous alignment of one was not a bug according to ANSI, but could cause code written for other ARM compilers to fail at runtime due to unaligned accesses. As an example, this could happen when casting a character pointer to an int pointer.
[EW14123]
Passing a pointer to long long as argument to a function could cause an internal error.
[EW14126]
Standard input in C-SPY with library buffered I/O enabled did not work. In addition, redirecting stdin from a file in C-SPY caused an application error.
If library buffered I/O was disabled, the standard input worked correctly.
[EW14174]

V3.30B 2003-03-18

When the compiler generated relay functions to Thumb assembler library routines, for example ??divu32, ??div32, ??divu16, ??div16, ??divu8, and ??div8, it accidentally destroyed the contents of non-scratch register R11. R11 is seldom used by Thumb code generation, but in ARM functions which call Thumb library code, this problem could surface if relay functions were needed. Now relay functions correctly use scratch register R12 instead.
[EW10737, EW13614]
When performing crossjump or hoisting optimizations, which is done on optimization levels -z9/-s9, the compiler incorrectly assumed that all inline assembler routines were identical. This could lead to an overly aggressive use of these optimization techniques, which resulted in incorrect code sequences to be generated.
[EW13638]
The compiler produced incorrect type information when compiling a file which contained a struct, one of whose fields was a pointer to another struct, and where the first struct was used in a context where its size or any offsets into it were not needed. The type information for the second struct was incorrect, which could lead to numerous incorrect type conflict warnings when linking.
[EW13651]

V3.30A 2003-02-18

va_arg() now works for structs that are not word-aligned.
[EW10145]
Formatted I/O functions, like printf, can now handle long long.
[EW10898]
The combined number of variables/functions per file is no longer limited to 64k.
[EW12299]
Using the same segment name multiple times as an argument to the __sfb() or __sfe() intrinsic functions resulted in an internal error:
Internal Error: [Front end]: compare_constants: bad address constant kind
[EW12783]
In some cases, assignments to elements in arrays with an unspecified size could be removed if the same element was used exactly once later in the same basic block.
[EW12790]
A remark that had been converted to a warning could not be suppressed using the --diag_suppress command line option.
[EW12847]
An internal buffer overflow could occur if a very long file name was used in combination with a very long function name. When this happened, the result could either be no diagnostic message, or one of the following two internal errors:
Internal error: [write_ABS_UBROF A01]: Illegal tag (P0: 0, P1: 0)
or
Internal error: [any]: Unexpected exception
[EW12851]
A casted pointer expression could result in an internal error similar to:
Internal Error: [AsmLine - OgAsm]: Error[43]: Illegal effective address
ADD R1,#+0x2
[EW12883, EW12884]
Peephole optimization of additions, where the first operand was known to be smaller than the type of the addition and the other operand was a negative constant, did not take the effects of propagated carry bits into account. If only a part of the sum was used (for example by shifting or masking the sum) and those bits came from the bits known to be cleared in the first operand, the result was optimized incorrectly.
[EW12973]
Incorrect code was generated for a pure 32-bit division when the divisor was a constant with a value of 2^n, and optimization was turned on. The problem was an incorrect mask constant.
[EW12975]
If a multiplication of two long long numbers was made in Thumb mode inside a leaf function (a function that does not call any other functions), the link register was not properly preserved for function return, which resulted in an eternal loop.
[EW12979]
If a switch statement contained only case constants that were impossible to reach due to the size of the switch expression type, an internal error occurred when no optimization was used.
[EW12983]
Accessing an element of an array in a packed structure type could cause a spurious warning:
Pa039: use of address of unaligned structure member
[EW12997]
In some cases where several structure members were assigned loop invariant values, the optimizer could mistakenly use the value from another member.
[EW13030]
The compiler could get into an infinite loop for certain loop constructs at optimization level -z6 and above.
[EW13031, EW13048]
An assignment from an array element to another in the same array could be optimized away at optimization level 4 and above, if the only use of the array after the assignment was to pass the array pointer itself to another function.
[EW13068]
Negating variables of type long long int previously generated incorrect code.
[EW13077]
At optimization level -z4 or higher, the compiler could give an internal error with the message: illegal state
[EW13160]
Incorrect code could be produced when the common subexpression and code motion optimizations were turned on (optimization level 7 and above).
[EW13169]
Multiplying a variable with itself could result in an unpredictable instruction (operand combination) being generated in Thumb mode.
[EW13171, EW13362]
In some cases, the sum of two expressions, where both expressions could be expressed as k*x + m (k and m are constants and x is a loop variable), could be calculated incorrectly.
[EW13184]
The compiler could hang on certain code constructs.
[EW13185]
There was a problem in auto-variable allocation that could cause two array or struct variables to be allocated to the same space on the stack, even when they were both alive at the same time.
[EW13186]
The code generated for a constant shifted by a 2^n scaled value inside a loop was incorrect, when compiled with High speed optimization.
[EW13222]
Common subexpression elimination depended on memory allocation order and could eliminate different expressions if the executing environment changed, for example if different operating systems were used.
[EW13251]
In some cases, optimization of repeated assignments could remove an assignment to an auto variable, even though it was still used.
p = q; p->next = p; p->prev = p;
could be transformed to
p->prev = p->next = q;
[EW13299]
When creating a temporary value from a common subexpression, the creation could be lifted above assignments to clustered variables that were part of that common subexpression. This caused the wrong clustered variable to be accessed.
[EW13332]
Thumb functions declared __irq no longer generate an internal error. But note that __irq functions cannot be compiled as __thumb.
[EW13337]
XLINK could erroneously report a type conflict for cases where some type attributes (like const or volatile) were part of a typedef type.
[EW13345]
If a loop contains multiple occurrences of variables that are only incremented in the loop, the increments of those variables can be hoisted out of the loop. The order of the hoisted increments no longer depend on memory allocation order.
[EW13352]
When compiling a new/delete expression in C++ code at optimizations of Medium or High, and the code for the constructor/destructor was not visible, the compiler sometimes referred to the special 'new constructor'/'delete destructor' by an incorrect name, resulting in undefined external errors when linking.
[EW13359]
A comma expression containing an assignment where a constant address was assigned another constant, *(unsigned char *)0x1234 = 17, caused an internal error.
[EW13375]
The assembler output generated from a string literal beginning with a tab character could not be assembled.
[EW13552]
If there were several calls with a different number of parameters via a relay function to a vararg or K&R function, one of the parameters could be destroyed.
[EW13564]
Inline assembler with several functions in different modes (__arm/__thumb) in the same source file could cause an internal error.
[EW13581]
In some cases, a common subexpression containing a clustered variable could be hoisted across a definition of that variable, if it occured in the same basic block as the common subexpression.
[EW13593]
Incorrect code was sometimes generated when combining shift and zero extension operations.
[EW13915]
When doing char (8-bit) arithmetics causing overflow, the generated code could make use of the overflowed value, that is, a larger value than 8 bits.
[EW14191]
When compiling code containing a combination of left and right shifts, the compiler performed an incorrect optimisation using a constant mask. This mask was calculated for an unsigned int even when the actual type used was signed int.
[EW14688]
Compiling code which used a combination of shift left and shift right, the compiler did an erroneous optimisation using a constant mask. This mask was calculated for an unsigned int even when the actual type used was signed int.
[EW14688]

V3.21A 2002-09-27

#pragma segment = <name>
Declares a segment name that can be used in the segment operators __segment_begin and __segment_end. Example:
#pragma segment = "MYSEG" __huge
__segment_begin(<name>)
__segment_end(<name>)
The __segment_begin operator denotes the start address of the segment with the name <name>, which must be a string literal and must have been declared in a segment pragma at an earlier point in the compilation unit. The __segment_end operator denotes the address immediately after the last byte in the segment. The type of these operators is pointer to void. If a memory attribute is entered in the segment pragma declaring the segment, the type is pointer to <memory> void, otherwise the type is a default pointer to void. The operator given in the example has the type "void __huge *".
Example:
__segment_begin("MYSEG")
#pragma required
The #pragma required will introduce a requirement from a symbol to another symbol, i.e. if the first symbol is in the produced output when linking the other symbol should also be in that output. This is useful if, for instance, a function that handles certain data should only be used if there is any data to handle.
Syntax: #pragma required=symbol where symbol is any statically linked function or variable. The #pragma must be placed in front of a symbol definition.
An example:
```
  void func(void)
  {
  // handle segment S or longVariable here
  }
  #pragma required = func  // longVariable requires f
  long longVariable @ "S"; // longVariable resides in segment S
```
The option --diagnostics_tables file|directory produces all possible diagnostics to a file. The default extension is txt. Default filename, if only a directory is specified, is diagnostics_tables.txt. It should only be used as a separate option to the compiler. This option is usefull if you have used #pragma diag... but forgot to document why, etc.
Libraries for big endian are now included.
Loop-invariant optimizations depended on OS memory allocation order.
[EW13215]
Inlined code could in rare cases give the following error:
Internal Error: [GoSyncStuff::FindPrecedingSync]: cannot find unique sync node.
[12852]
The compiler now generates the Thumb mnemonics LDRSB and LDRSH instead of the older LDSB and LDSH.
[EW12310]
Loop optimizations could generate incorrect array index.
[EW12325, EW12326, EW12409]
Code that handles small unaligned structures could generate an internal error.
[EW12403]
Code for casting to signed and unsigned long long could sometimes result in incorrect values.
[EW12404]
Code generated to access to nonaligned structures could be incorrect.
[EW12405, EW12406]
A constanttable inserted after a function that had been cross-jumped could result in an internal error.
[EW12407]
An optimization bug could cause incorrect code to be generated.
[EW12408]
Short elements in a union stored in a register could be incorrectly aligned.
[EW12410]
A cast operation could sometimes incorrectly be optimized away.
[EW12512]
The code generated by the compiler could change depending on the compiler execution environment. The generated code was correct but the size could differ. The sensitivity to change in execution environment could be moving to a different Windows OS, changing the environment settings, length of file paths and other changes that could change the memory allocation order within the compiler process.
[EW11219, EW12580]

V3.20A 2002-06-18

The runtime model has changed from version 3.11A. The current __rt_version is 4.
ARM instruction set version 5TE is now supported.
To use it add command line option --cpu {target core or architecture name}.
It is now possible to mix code compiled with small and large code models.
The interworking code model is now supported through the new command line option --interwork.
The calling convention is now ATPCS as default. Interwork must still be added if needed to a function with function-type attribute __interwork or globally with the command line option --interwork.
Access to floating point flags has been re-engineered. Refer to the file MathFloatFlags.h for more information.
Two functions from the ANSI C99 standard have been included: snprintf() and vsnprintf().
Evaluation of else-if could be performed incorrectly at high speed optimization in Thumb mode.
[EW12287]
The char pointer member of a structure object used as parameter was not passed correctly to the called function. This occurred at high optimization levels.
[EW12248]
The combination of Thumb mode and high speed optimization could lead to incorrect code when testing bitfield values.
[EW12227]
Structure return values from __pcs functions that are less than 32-bit and not aligned to an even 4-byte address would be returned indirectly using an implicit extra parameter.
[EW10358]
Register mismatch in debug information between compiler and linker when output was ELF/DWARF.
[EW10703]
Library functions assert, strchr and strrchr could not be used with string literals in C++.
[EW10899]
The compiler could previously generate multiplication instruction with undefined behavior: MUL R0,R0,R4.
[EW11114]
The intrinsic functions __sfb/sfe could only be used once per segment, multiple uses would result in link failure.
[EW11122]
A small part of the runtime library was broken. It used the wrong register in a BX instruction.
[EW12060]
Certain __swi function definitions could result in an incorrect warning.
[EW11247]
The compiler generated incorrect code for switch statements where the body code and at least one case except the last did not end with a break or a goto.
[EW11336, EW11337, EW11360]
The compiler could generate incorrect code for a bitfield value test at high-speed optimization.
[EW11371]
Nested loops using the same loop variable could be optimized incorrectly if the increment or decrement of the loop variable preceded the inner loop.
[EW11372,EW11423]
Read access to smaller union fields in register allocated unions could destroy other union fields of different size.
[EW11373, EW11381]
Some code optimization and analysis problems were corected. They either resulted in "Internal error" or the compiler never terminated.
[EW11374, EW11375, EW11376]
Corrected a problem where partial object assignments were interpreted as an assignment of the whole object. This could cause incorrect elimination of assignments.
[EW11377, EW11418, EW11424, EW11427]
The compiler is now a little more restrictive when optimizing address expressions. This avoids incorrect assumptions while compiling code that does not conform to ANSI C.
[EW11378, EW11422]
Variable initialization could in some cases be optimized away.
[EW11380]
Sometimes loops that were unrolled to straight line code could be optimized incorrectly.
[EW11416, EW11425]
When for or while loops were fully unrolled, side effects in the test would not be executed for the final iteration.
[EW11417, EW11426]
Expressions like a > b + 1 were rewritten as a > = b, but that changed the behavior when the expression b + 1 would have overflowed.
The ANSI C standard allows the transformation, since the behavior at overflow is unspecified. But the expressions are no longer transformed since it changed the expected behavior.
[EW11490, EW10978]
Using integer division or modulo in __ramfunc could result in an internal error.
[EW11999]
Relay from located functions could result in:
Internal error [OgModuleLabels::Def::Define]: Label already defined.
[EW12011]
A number of code-generation and optimization bugs have been corrected.
[EW11419, EW11420, EW11421,EW11862]
The file checkDefs.i included by cstartup.s79 was missing from the distribution.
[EW11223]
The code generated for __disable_interrupt() has been rewritten in a more secure way.
[EW11143]
Crossjump between two or more small functions could destroy LR is the distance between them is too far.
[EW12808]

V3.11A 2001-12-04

The floating point library now has exception flags. Refer to the file MathFloatFlags.h for more information.
Long long is now supported, except in the formatted I/O functions.
A new command line option, --omit_types, omits function/variable type info in object output.
An assignment between two elements from packed structures could generate a misaligned access.
[EW10299]
Structure parameters to __pcs functions larger then 64 bit or not aligned to an even 4-byte address were always placed on the stack.
[EW10357]
__pcs functions could in some cases get incorrect backtrace information.
[EW10359]
Several corrections in long long support.
[EW10364]
Loop optimization could hoist an expression before its definition.
[EW10421]
String literals now have the type "array of const char" in C++.
[EW10542]
Values casted to and compared in a type smaller than 32-bit could be destroyed.
[EW10569]
When compiling a while loop following immediately after a case label in a switch, the compiler could crash if high optimization was used (-s9 or -z9).
[EW10725]
The intrinsic functions __sfb, __sfe and __sfs yield an error when the referred segment is not otherwise used in the module.
[EW10757]
Cross call optimization could generate a fatal error in some cases where several similar functions had multiple exits.
[EW10807]
Register allocation could in some rare cases with extreme register pressure generate a "coloring failed" error.
[EW10868]

V3.10A 2001-10-02

The runtime model has changed from version 2.10. The current __rt_version is 2.
New floating point library with smaller code size and greatly improved speed.
Debug information is improved, with better variable information and backtrace.
A switch statement of the form switch(a-b<=0) at higher optimization levels than 3 caused the wrong case to be selected.
[ARMC0021]
Inline expansion of memcpy() could produce the wrong result.
[ARMC0022]
Assignment loop using loop index caused incorrect code at -z9.
[ARMC0027]
Bitfields could not be larger than 255 bits.
[LB397]
Global optimizer problems which resulted in internal error has been corrected
[EW10178 (LB399)]
Global optimizer problems which resulted in incorrect code has been corrected.
[EW10082, EW10102, EW10180 (LB401), EW10181 (LB402), EW10182 (LB403)]
Call via function pointer now sets the correct mode bit in return address.
[EW10313]
A problem in the register allocation algorithm could cause "Internal error: [CgDriver]: Coloring failed".
[EW10087]
Too aggressive optimizations when shifting bitfields.
[EW10080]
Call to a variadic __pcs function with K&R declaration with different number of arguments could cause an internal error.
[EW10083]
A faulty optimization rule could cause Thumb instructions to use illegal high registers.
[EW10292]
Header files for C++ not installed.
[EW10294]
The gmtime() could cause corrupt tm structure values for arbitrary time values, the tm_mday for example could turn negative. There was also a problem that the mktime() function could corrupt tm structure values.
[EW10363]

V2.10D 2001-06-27

Loop optimizations have been reorganized and several problems have been corrected.
[Lb 355,375,376,379,382,390,396]
Corrected a problem in the ARM mode peephole optimizations. Could cause an unintialized register to be used.
[ARMC0018]
Corrected a problem that caused compiler to loop if ARM mode was used and the code had a large modulo expression.
[ARMC0017]
Part of the exit sequence could be optimized away (restoring high registers in Thumb mode).
[ARMC0016]
Fixed problem where a constant casted to a pointer caused incorrect code randomly.
[ARMC0015]
CStartup used to have a reference to SVC_STACK that was neither used in the code nor declared in the standard linker command file lnkarm.xcl.
[ARMC0011]
#pragma swi_number can now be fitted to either the function declaration or the function definition.
[ARMC0009]
Fixed code for passing structures as parameters. The code was either incorrect or the stack was not aligned correctly.
[ARMC0007]

V2.10A 2001-02-21

The compiler now supports Embedded C++.
It is now possible to choose between big and little endian byte order.
Support for the ARM9TDMI core has been added.
The following command line options have been added or changed:
- --ec++ add support for ec++ syntax
- --cpu [arm7tdmi | arm9tdmi] select processor
- --endian [big | little] select memory format
- --no_scheduling disables instruction scheduling
A program with struct accesses in different scopes but casted from the same variable could be transformed incorrectly.
[Lb 388]
Too aggressive optimizations with partial updates of variables.
A change of sign was sometimes introduced in unsigned character switches.
Incorrect code was generated in loops at high speed optimizations.
[Lb 381]
An internal error was received when the > operator was used with unequal types in loops at high optimizations.
[Lb 380]
The recognition code for packed structures was incorrect.
[Lb 378]
A problem occuring when accessing fields in packed structures has been corrected.
[Lb 374]
Accessing array members of struct return values could give an internal error.
[Lb 365]
Correcting a problem occuring in Thumb mode on high optimization level when adding a constant offest to an address (label).
[ARMC0004]
The following code used to give an internal error:
int fn_dbl(double);
int fn_dbl(f) float f; { do_nothing(&f); return 97; }
[Lb 364]

V1.30C 2000-10-14

A problem in cstartup has been corrected, constants where put after each segment even when fall-through was used.
[ARMC0003]
A problem sometimes resulting in an internal error "coloring failed" in Thumb mode has been corrected.
[ARMC0002]

V1.30A/B 2000-09-28

Support for handling interrupt functions has been added.
The following function type attribute keywords have been added:
- __irq - declares an interrupt function.
- __fiq - declares a fast interrupt function.
- __swi - declares a software interrupt function.
The following #pragma directive has been added:
#pragma swi_number=<number>
For more information about interrupt functions, see Manual corrections in this document, tutor\interrupt_example.c, inc\arm_interrupt.h, and src\lib\swi_handler.s79.
The following intrinsic functions have been added:
- __intrinsic int __sfb(void *) - returns address to beginning of segment
- __intrinsic int __sfe(void *) - returns address to end of segment
- __intrinsic int __sfs(void *) - returns size of segment
Code for spilling and unspilling high registers in Thumb mode has been corrected.
[ARMC0001]
A problem that under some circumstances could result in a never-ending compiler internal loop is corrected.
Volatile objects referred by a pointer, are now handled correctly.

V1.20A 2000-05-28

The following C library functions will under certain circumstances be handled as intrinsic functions and will generate inline code instead of an ordinary library call: memcpy, memset, strcpy, strlen, strncpy, strcat, strcmp, strncmp

V1.10B 2000-01-14

Minor corrections.
Switch statements in ARM mode are now implemented more efficiently, using jump tables.

V1.10A 1999-12-30

First release.