Release notes for ARM Compiler Toolchain 5.01u3

Enhancements in 5.01u3

General

• Support for the Cortex-M0+ CPU has been added. To target the Cortex-M0+ use --cpu=Cortex-M0+ [SDCOMP-15444]

Corrections in 5.01u3

Assembler (armasm)

• When using banked register MSR/MRS instructions, fromelf and the assembler would not correctly identify undefined encodings. This has been fixed. [SDCOMP-18246]

Compiler (armcc)

• When performing struct reads and writes the compiler now treats volatile fields in structs, and fields in volatile structs, as distinct volatile objects and generates a load or store for each such field as if it were directly accessed. [SDCOMP-18442]
• The compiler now uses the __aeabi_uread8 and __aeabi_uwrite8 functions at -Ospace for performing unaligned 8-byte loads and stores on CPUs which do not support unaligned accesses. [SDCOMP-18375]
• In situations at -O3 -Otime, a while loop with huge constant stride could be transformed so that the compiler creates an expression that will cause an arithmetic overflow. [SDCOMP-18368]
• Under certain circumstances the compiler would optimise algebraic identities even when there were intervening operations that could potentially change memory. This has been fixed. [SDCOMP-18352]
• Under certain circumstances, loops with small constant iteration counts may be incorrectly transformed into infinite loops when both unrolling and loop rotation are applied to the loop. [SDCOMP-18323]
• In some situations at -O2 and above a sequence of accesses to non-contiguous array or structure members could cause the calculation of the memory offset within that array or structure to be incorrect. This has been fixed. [SDCOMP-18168]
• A compiler optimization related issue caused a pointer to be indexed and incremented incorrectly in a loop. This has been fixed. [SDCOMP-17924]
• Under certain circumstances, the compiler could generate out-of-bound stack accesses to an array variable or variadic argument, which could cause reading from uninitialized memory. This is now fixed. [SDCOMP-17753]
• armcc will no longer produce internal fault 0x05ced5 when a de-referenced function pointer is used on the left-hand side of an assignment. Instead armcc will produce error #137. [SDCOMP-17734]
• When compiling to Thumb code for a target without Thumb-2, large functions that contain lots of 64-bit integer operations could trigger internal fault 0x995e1d. This has been fixed. [SDCOMP-17628]
• In some cases, switch statements could trigger an internal fault in the compiler at -O1 and above. This has been fixed. [SDCOMP-17588]
• In some cases when compiling for Thumb, a CMP instruction would be omitted after an indirect or virtual function call. This has been fixed. [SDCOMP-17438]
• Previously the alignment of fields with array types in packed structures was not being honored during field access operations, except when --gnu was specified. This could result in erroneous unaligned memory accesses. The compiler now correctly honors field alignment in all cases and no longer generates incorrect unaligned memory accesses. [SDCOMP-17029]
• The cause of compiler internal fault 0x87ecef has been fixed. [SDCOMP-16775]
• In some circumstances compiling code that makes use of the GNU gnu_inline attribute at optimisation levels above -O0 could result in incorrectly generating recursive functions where no such recursion should exist. The gnu_inline attribute has now been correctly implemented. Note that the gnu_inline attribute is not currently supported on functions with exception specifications when exceptions are enabled. [SDCOMP-16351]
• The use of --remove_unneeded_entities with --debug could cause internal faults in the compiler in some cases. The general stability of this feature has been improved. [SDCOMP-15817]
• A cause of internal fault 0x05ced5 when compiling with --remove_unneeded_entities has been fixed. [SDCOMP-15808]
• A cause of internal fault 0x6bca8b when compiling with -O3 -Otime has been fixed. [SDCOMP-15725]
• When using the options --asm and -M or -MM together the compiler would give an internal fault. This is now fixed. [SDCOMP-15487]

Libraries

• Incorrect pointer arithmetic in the scanf library functions when building with --wchar32 could cause incorrect behaviour at runtime. This has been fixed. [SDCOMP-17985]
• The use of 4-byte wchar_t in conjunction with the stdio wide character support (e.g. fgetwc, ungetwc, fwscanf) could corrupt data used by the rest of stdio, including the mutex used to keep multithreaded applications safe, and could also lead to wrong behaviour if ungetwc or scanf were used together with file positioning functions such as fseek. This is now fixed. [SDCOMP-17901]