Release notes for ARM Compiler toolchain 5.01u2

Enhancements in 5.01u2

Corrections in 5.01u2

Assembler (armasm)

• Previous version of the assembler implemented vector notation incorrectly for 3-operand vector-mode VFP instructions. For mixed scalar-vector operations, the assembler expected the operands to be in the order "vector,scalar,vector", while the correct form is "vector,vector,scalar". This correct use of vector-mode operations would be faulted with an error, while incorrect instructions would be permitted. This has now been fixed. [SDCOMP-17026]

Compiler (armcc)

• In certain circumstances, when using a 64bit shift, the compiler could corrupt the result of a following compare, and hence generate incorrect code. This is now fixed. [SDCOMP-17161]
• When using named register variables on v7-M profile cores, the compiler would only generate MRS/MSR instructions for APSR even if another register e.g. PRIMASK was used. [SDCOMP-17132]
• The compiler was incorrectly defining the target FPU macros, such that it was only defining the base VFP varient. For example, when using --fpu=vfpv3_d16, __TARGET_FPU_VFP and __TARGET_FPU_VFPV3 would be defined. Now __TARGET_FPU_VFP, __TARGET_FPU_VFPV3 and __TARGET_FPU_VFPV3_D16 are defined. [SDCOMP-17054]
• In certain circumstances for MPCore, the compiler could generate redundant NOP instructions after a branch instruction. [SDCOMP-16997]
• In certain circumstances when using long long data types, the compiler could generate an internal fault 0x25d84c. This has now been fixed. [SDCOMP-13917]
• Since 4.1b631, including a PCH header file with inline assembly in it could result in internal fault 0xbbac9a, and in rare cases incorrect code generation. This is now fixed. [SDCOMP-13737]
• The compiler previously did not take into account program control flow when vectorizing loops, and hence would conservatively deem vectorization of some loops unsafe. The compiler now takes control flow into account when vectorizing loops. [SDCOMP-11117]

Libraries

• The microlib realloc() function fails to copy the input data into the returned location, if the new block happens to be allocated in such a way that it fits exactly into a free block in the heap (rather than the more usual case of using up only part of a free block). This is now fixed. [SDCOMP-17250]