Release notes for ARM Compiler toolchain 5.04 (2024)

Please contact support for more information about this release.

Enhancements in ARM Compiler 5.04 update 5

General enhancements

[SDCOMP-23478]Implemented --debug_info=line_inlining_extensions as a compiler option. Within the line table, entry to an inlined function is indicated by DW_LNE_lo_user and exit from an inlined function is indicated by DW_LNE_lo_user+1.

Defect fixes in ARM Compiler 5.04 update 5

Compiler (armcc)

[SDCOMP-29633]When a static variable in an inline function or an inline class member function has a section attribute, this attribute was ignored and the variable was placed in a section with a different name from the name given by the attribute. This could also cause an Internal fault. This has been fixed.
[SDCOMP-29544]In certain circ*mstances, when compiling at -O3 -Otime, the compiler could incorrectly assume that the values of elements in a multi-dimensional array would not change from their initial values. This could result in incorrect code. This has been fixed.
[SDCOMP-29543]In certain circ*mstances, when compiling at -O3 -Otime, the compiler could incorrectly fail to sign extend the return value for a function that returns a signed integer when the expression receiving the returned value is of a wider integer type. This has been fixed.
[SDCOMP-29542]In certain circ*mstances, when compiling at -O3 -Otime, the compiler could incorrectly treat the result of an equality operator or a relational operator as unsigned int instead of int. This has been fixed.
[SDCOMP-29464]In rare circ*mstances, when compiling at -O1 or above, the compiler could generate a sequence of code that incorrectly used a flag-setting instruction, corrupting the flags required by a subsequent flag-reading instruction. This has been fixed.
[SDCOMP-29304]In rare circ*mstances, when compiling at -O2 or above, the compiler could generate incorrect code when the result of an arithmetic expression containing a bitwise Exclusive OR and a bitwise OR operator is assigned to a variable of integer type that is smaller than a 32-bit integer. This has been fixed
[SDCOMP-29280]In rare circ*mstances, when compiling at -O1 or above, the compiler could generate incorrect code when a location in memory is written to without using volatile followed by another write to the same location that does use volatile. This has been fixed.
[SDCOMP-29267]In rare circ*mstances, when compiling at -O2 or above, the compiler could incorrectly optimize an expression involving two operators that are either:
- Both bitwise OR.
- Both bitwise Exclusive OR.
- A combination of bitwise OR and bitwise Exclusive OR.
This has been fixed.
[SDCOMP-29261]In rare circ*mstances, when compiling for Thumb state, the compiler could generate incorrect code for a program that reads from a number of contiguous memory locations where it can be determined that some of the reads can be eliminated. This could result in a failure to load some of the required data. This has been fixed.
[SDCOMP-29252]In rare circ*mstances, when compiling at -O2 or above, the compiler could incorrectly allocate variables local to a block of code to the same memory locations as variables outside of the block of code. This has been fixed.
[SDCOMP-29222]In rare circ*mstances, when compiling for ARM state, the compiler could generate incorrect code for calculating offsets to data stored in contiguous memory locations. This could result in a value being written to or read from an incorrect address. This has been fixed.
[SDCOMP-29191]In rare circ*mstances, when compiling with -Otime --vectorize at -O2 or above, the compiler could generate incorrect code when vectorizing a loop that writes to an array. This has been fixed.
[SDCOMP-29189]In rare circ*mstances, when compiling with -Otime --vectorize at -O2 or above, the compiler could generate incorrect code for a loop that casts the elements of an array of integer type to float to perform a floating point calculation, and the result is cast back to an integer type for further calculations. This has been fixed.
[SDCOMP-29160]In certain circ*mstances, when compiling at -O3 -Otime, the compiler could generate incorrect code for a for loop that modifies a pointer which aliases the loop index. This could result in an incorrect number of iterations of the loop. This has been fixed.
[SDCOMP-29158]In rare circ*mstances, when compiling at -O3 -Otime, the compiler could generate incorrect code for a program containing nested for loops, resulting in an inner loop body incorrectly being executed. This has been fixed.
[SDCOMP-29157]In rare circ*mstances, when compiling at -O3 -Otime, the compiler could generate incorrect code for expressions of the form A & B when one of A or B can be evaluated at compile time to zero and the other expression contains an increment or decrement operator. This has been fixed.
[SDCOMP-29155]In rare circ*mstances, when compiling at -O3 -Otime, the compiler could generate incorrect code when a parameter of a function is always passed the same value, and the value is not in range of the type of the parameter. This has been fixed.
[SDCOMP-29151]In rare circ*mstances, when compiling at -O3 -Otime, the compiler could generate incorrect code for a control statement having a controlling expression of the form A <= B or A > B, where expression A can be evaluated at compile time to zero and B is of an unsigned type. This has been fixed.
[SDCOMP-29117]In rare circ*mstances, when compiling at -O2 or above, the compiler could generate code containing execution paths that do not have correctly balanced PUSH and POP instructions. This could corrupt the stack, resulting in incorrect behavior. This has been fixed.

Libraries

[SDCOMP-29102]The C library function strftime() would generate incorrect results when using the %C or %h format specifiers. This has been fixed.

Other issues

[SDCOMP-29337]In certain circ*mstances, the compiler could incorrectly generate Error: C9558E: System clock tampering detected. License checkout will fail. if files with very old timestamps were present in the file system. This has been fixed.

General changes in ARM Compiler 5.04 update 4

[SDCOMP-28484]The control of license management warnings has been improved:
- The --diag_remark and --diag_suppress options can now be used to downgrade all license management warnings.
- The --diag_error=warning option now upgrades all warnings except for license management warnings to error severity.

Enhancements in ARM Compiler 5.04 update 4

General enhancements

[SDCOMP-23478]Implemented --debug_info=line_inlining_extensions as a compiler option. Within the line table, entry to an inlined function is indicated by DW_LNE_lo_user and exit from an inlined function is indicated by DW_LNE_lo_user+1.

Defect fixes in ARM Compiler 5.04 update 4

Compiler (armcc)

[SDCOMP-29257]In certain circ*mstances, the compiler could produce incomplete debug information for data that is allocated to registers rather than memory. This has been fixed.
[SDCOMP-29030]At -O3 -Otime, in rare circ*mstances the compiler could generate incorrect code for expressions of the form A relational-operator B when both A and B are of integer type and have known values at compile time. This has been fixed.
[SDCOMP-29029]At -O3 -Otime, in rare circ*mstances when compiling a for loop that has an iteration variable X where X is of signed integer type, has an initial value that is not known at compile time, and that may overflow the value range for its type, the compiler could generate incorrect code that fails to enter the loop body for all the expected initial values of X. This has been fixed.
[SDCOMP-29028]At -O3 -Otime, in rare circ*mstances when compiling an if statement having a controlling expression that can be evaluated to false at compile time, the compiler could generate code which incorrectly failed to execute function calls contained in the controlling expression. This has been fixed.
[SDCOMP-29026]At -O3 -Otime, in rare circ*mstances when compiling a for loop that has an iteration variable X where X is of signed char or signed short type, has an initial value that is known at compile time, and that may overflow the value range for its type, the compiler could generate incorrect code that fails to enter the loop body. This has been fixed.
[SDCOMP-28950]When compiling for Thumb state at -O2 or above, the compiler could generate a MULS instruction between a flag-setting instruction and a conditional instruction, resulting in incorrect behavior. This has been fixed.
[SDCOMP-28895]At -O3 -Otime, the compiler could generate incorrect code for a function that is inlined into the body of a loop when the function contains a local array variable with an initializing expression. This has been fixed.
[SDCOMP-28669]When compiling for ARM state at -O2 or above, in rare circ*mstances involving a conditional expression the compiler could report an Internal fault. This has been fixed.
[SDCOMP-28651]In certain circ*mstances, the compiler could generate incorrect code for a chained struct or class assignment x = y = z resulting in the rvalue expression, z, being evaluated more than once. This has been fixed.
[SDCOMP-28552]At -O2 and above, in rare circ*mstances the compiler could generate incorrect code when compiling nested conditional expressions or statements involving variable assignments. This has been fixed.
[SDCOMP-27405]When compiling for Thumb state, the compiler could generate incorrect code when explicitly or implicitly adding, subtracting, or comparing to an integer constant and that constant cannot be directly encoded in the immediate field of an ADD or ADDS instruction. This has been fixed.
[SDCOMP-25836]At -O3 -Otime, in rare circ*mstances a combination of optimizations could result in an incorrect transformation, causing the compiler to report an Internal fault. This has been fixed.
[SDCOMP-25725]When compiling for Thumb state at -O3, in rare circ*mstances involving many expressions the compiler could report an Internal fault. This has been fixed.

Linker (armlink)

[SDCOMP-26071]When resolving a relocation to a linker-generated Load$$ symbol, if RW data in one or more preceding execution regions is compressed, the linker could incorrectly calculate that value of the symbol. This has been fixed.

Libraries

[SDCOMP-28672]The std::deque::operator++() and std::deque::operator+=() methods implemented in deque and deque.cc contained errors that could load data from memory beyond the area allocated for the deque. This could result in a Data Abort. This has been fixed.
[SDCOMP-28636]The std::vector::operator=() method implemented in vector.cc contained an error that could result in incorrect behavior when the size of the destination vector is larger than the size of the source vector. This has been fixed.
See Also
µVision User's Guide: Arm C/C++ Compiler Release notes for ARM Compiler toolchain 5.04 How to make 3DS Games with Unity

Other issues

[SDCOMP-28980]When preprocessing a scatter-file using ARM Compiler 5.04 update 3 (build 146), the link step could require two compiler licenses concurrently. This has been fixed.

General changes in ARM Compiler 5.04 update 3

[SDCOMP-25859]ARM Compiler 5.04 update 3 includes FlexNet Publisher 11.12.1.0 client libraries. This version of the license client is not compatible with previous versions of the FlexNet Publisher license server software:
- ARM Compiler 5.04 update 3 will report FLEXnet Licensing error:-7,10015 when used with a license server running an armlmd or lmgrd version earlier than 11.12.1.0.
- A license server running armlmd and lmgrd version 11.12.1.0 (or later) is compatible with ARM Compiler 5.04 update 3 and all previous releases of ARM tools.
FlexNet Publisher 11.12.1.0 (or later) license server software can be downloaded from https://silver.arm.com/browse/BX002 (login/registration required).

Enhancements in ARM Compiler 5.04 update 3

General enhancements

[SDCOMP-23478]Implemented --debug_info=line_inlining_extensions as a compiler option. Within the line table, entry to an inlined function is indicated by DW_LNE_lo_user and exit from an inlined function is indicated by DW_LNE_lo_user+1.

Defect fixes in ARM Compiler 5.04 update 3

Compiler (armcc)

[SDCOMP-26023]In certain circ*mstances, the compiler could report an Internal fault when compiling code containing NEON intrinsics. This has been fixed.
[SDCOMP-25946]At -O2 and above, in certain circ*mstances the compiler could generate a sequence of code that incorrectly contains a flag-setting variant of an instruction rather than the non flag-setting variant. This could result in a subsequent branch instruction having incorrect behavior. This has been fixed.
[SDCOMP-25900]At -O3 -Otime, the compiler could generate incorrect code for a loop that contains only if statements with bodies that are never executed and are either empty or contain only a break or continue statement. This has been fixed.
[SDCOMP-25894]At -O1 and above, when reading a bitfield of type long long or unsigned long long from a struct that has been declared packed using any of __attribute__((packed)), #pragma pack(n), or the __packed qualifier, and the code is not compiled for unaligned accesses, the compiler could generate code that loaded data from memory beyond the end of the struct. This has been fixed.
[SDCOMP-25845]The compiler could generate incorrect code for a chained struct assignment if the left-hand side of the assignment is a volatile variable and the right-hand side is another assignment expression that does not involve an assignment to or from a volatile variable. This has been fixed.
[SDCOMP-25830]The compiler could generate incorrect code for a copy assignment of a struct that contains both non-volatile and volatile bitfields. This has been fixed.
[SDCOMP-25811]When using --diag_warning=error to downgrade error messages to warning severity, the compiler could incorrectly fail to generate an object file even though it returned a zero exit code. This has been fixed.
[SDCOMP-25761]At -O2 and above, in certain circ*mstances the compiler could generate incorrect code when integer constant values with the same binary representation are used in two different expressions, and the first of these expressions includes a logical Exclusive OR. This has been fixed.
[SDCOMP-25753]At -O3 -Otime, when a loop contains two pointers that point to the same array and contains a sequence of statements that read from and/or write to the array through these pointers, the compiler could incorrectly reorder these statements. This has been fixed.
[SDCOMP-25643]When processing embedded assembly language that contains a constant string of length greater than 128 characters, the compiler could incorrectly report Error: A1154E: Unexpected operand, operator expected. This has been fixed.
[SDCOMP-25575]The compiler could generate incorrect code for accesses to a volatile bitfield member of a struct where the bitfield container is narrower than the bitfield container type but wider than one byte. This has been fixed.
[SDCOMP-25485]When compiling with -Otime --vectorize at -O2 or above, a loop that copies an array of structures in decreasing address order could be incorrectly transformed by the compiler into a copy by increasing address order. This could result in incorrect behavior when the source and destination memory areas overlap. This has been fixed.
[SDCOMP-25347]At -O3 -Otime, when a function declares and initializes two variables A and B, the initialization of B calls a function F() with an argument that depends on A, and the initialization of both variables involves a call to a virtual member function or function pointer, the compiler could incorrectly generate two calls to F(). This has been fixed.
[SDCOMP-25117]At -O2 and above, the compiler could generate incorrect code when assigning a pointer dereference to a variable, then setting the location that was dereferenced to a different value, and then using both the variable and the new value of the pointer dereference in the same expression. This has been fixed.
[SDCOMP-25085]At -O3 -Otime, the compiler could generate incorrect code for a for statement in which expression-3 performs an array copy. This has been fixed.
[SDCOMP-25034]The compiler could generate incorrect code for a function call with a 64-bit integer argument that is read from a struct declared within the scope of a #pragma pack(2) or a #pragma pack(4). This has been fixed.
[SDCOMP-25005]When compiling for an ARMv7-M target at -O3 -Otime --loop_optimization_level=2, the compiler could generate incorrect code for a while loop in which the controlling expression post-increments a variable that is used to index an array in both the controlling expression and the loop body. This has been fixed.
[SDCOMP-24936]At -O0, the compiler could generate incorrect code for certain relational expressions containing an operand that is a bitwise AND of a long long expression and a large constant with exactly one bit set. This has been fixed.
[SDCOMP-24897]When compiling an assignment in which the operands are of struct or class type and the right operand contains a volatile unnamed bitfield of size 0, the compiler would either fail with an Internal fault or would generate incorrect code. This has been fixed.
[SDCOMP-24711]When a bitfield member of a struct is declared with the aligned(n) attribute having n greater than 1, and either that bitfield or the struct is packed, the aligned(n) was incorrectly treated as if it were aligned(1). This has been fixed.

Assembler (armasm)

[SDCOMP-25862]When assembling the MSR instruction for an ARMv7-M processor, the assembler did not recognize the _<bits> qualifier for the IAPSR, EAPSR, and XPSR registers. This has been fixed.

Libraries

[SDCOMP-25856]When computing the complex inverse sine of a real number strictly between -1 and 1, the casin(), casinf(), and casinl() library functions would incorrectly return the imaginary part of the result as NaN instead of 0. This has been fixed.

Enhancements in ARM Compiler 5.04 update 2

General enhancements

[SDCOMP-23478]Implemented --debug_info=line_inlining_extensions as a compiler option. Within the line table, entry to an inlined function is indicated by DW_LNE_lo_user and exit from an inlined function is indicated by DW_LNE_lo_user+1.

Defect fixes in ARM Compiler 5.04 update 2

Compiler (armcc)

[SDCOMP-24893]At -O3 -Otime, the compiler could generate incorrect code for a loop containing a post-incremented variable. A pre-increment operation would be generated instead of a post-increment operation, which could cause incorrect loop behavior. This has been fixed.
[SDCOMP-24747]In certain circ*mstances the compiler could crash when compiling C++ code with the --protect_stack option. This has been fixed.
[SDCOMP-24731]When using the inline assembler with a quoted string construct, for example, __asm("MOV a, b");, the preprocessor would preprocess the assembly code inside the string by mistake. This has been fixed.
[SDCOMP-24730]At -O1 and above, when compiling an integer divide expression for an ARMv7-M target, the compiler could generate incorrect code that may result in a fault when run with trapping of divide by zero enabled. This has been fixed.
[SDCOMP-24675]If a pointer to a class A, pointing to an object of a class B indirectly derived from A, was cast with dynamic_cast to a class C from which B was also derived and from which A is not derived, then the compiler could incorrectly remove some information from the output object file. This would cause the linker to delete the Run-Time Type Information (RTTI), and would make the dynamic_cast fail with a runtime type check failure. This also applied to references as well as pointers. This has been fixed.
[SDCOMP-24655]At -O1 and above, the compiler could miscompile a sequence of code in which a variable was incremented by a constant value and was then used in a conditional expression in which it was decremented by the same, constant value. This has been fixed.
[SDCOMP-24526]In some circ*mstances, the compiler could generate incorrect code for reading and writing packed long long bitfields. This has been fixed.
[SDCOMP-24520]In certain situations when compiling for Thumb-2 and involving closely chained comparisons, such as computing abs(x) and immediately comparing it with another value, the compiler could mistakenly generate a SUB instruction rather than a flag setting SUBS instruction. This could result in incorrect behavior. This has been fixed.
[SDCOMP-24506]If a value was stored in a local variable with an integer type smaller than four bytes using a __strt, __strex, or __swp intrinsic, the compiler could generate code that failed to sign-extend or zero-extend subsequent reads of that variable when required to do so. This has been fixed.
[SDCOMP-24493]At -O2 and above, in certain situations involving a sequence of loads or stores to a contiguous area of memory, the compiler could generate an LDM, STM, VLDM, or VSTM instruction with an uninitialized or incorrectly initialized base register for part of the sequence. This has been fixed.
[SDCOMP-23837]At -O2 and above, in some circ*mstances the compiler could incorrectly transform a CMP instruction followed by an instruction that tests for a MI or PL condition by changing the condition from MI to PL, or vice-versa, and swapping the order of the CMP operands. This would lead to incorrect behavior where the CMP operands are equal, or differ by 0x80000000. This has been fixed.

Linker (armlink)

[SDCOMP-24101]When linking a program using --rwpi, --ropi, --fpic, --reloc, or the PI or RELOC attributes in the scatter-file, the linker could incorrectly insert two bytes of padding between a veneer and a subsequent scatter-loading handler. When using the --pad option, the padding bytes would be set to the --pad value and this could result in an arbitrary or undefined instruction being executed. This has been fixed.
[SDCOMP-24054]To generate correct veneers, the linker must first finalize the order of the sections within an execution region. In rare circ*mstances, when linking a large program, the linker could incorrectly change the order of the sections after veneers had been inserted. If an inline veneer was created for a section that was subsequently moved, incorrect behavior would occur whenever that veneer was called because execution would transfer to a different section than the one that was expected. This has been fixed.

Libraries

[SDCOMP-23977]When initializing an object of type std::priority_queue using the constructor that takes only Compare and Container arguments, the library code failed to call make_heap. This would result in top returning values in an incorrect order. This has been fixed.
[SDCOMP-23881]Use of a %*n directive in a scanf-family function would behave the same as %n, instead of doing nothing as C90 requires. This has been fixed.
[SDCOMP-23765]When the %[ conversion specifier for a scanf-family function fails to match any input characters, the corresponding argument should be unaffected. Instead, the argument would have had '\0' written to its first byte. This has been fixed.

Enhancements in ARM Compiler 5.04 update 1

General enhancements

[SDCOMP-23838]Support for the Cortex-A17 CPU has been added. To target the Cortex-A17 select from the options:
- --cpu=Cortex-A17 with NEON and VFP support.
- --cpu=Cortex-A17.no_neon.no_vfp with no NEON and no VFP support.
[SDCOMP-23478]Implemented --debug_info=line_inlining_extensions as a compiler option. Within the line table, entry to an inlined function is indicated by DW_LNE_lo_user and exit from an inlined function is indicated by DW_LNE_lo_user+1.

Defect fixes in ARM Compiler 5.04 update 1

Compiler (armcc)

[SDCOMP-23768]At -O2 and above, in rare circ*mstances the compiler could generate an incorrect sequence of stores for assignments to data members of a struct or class. This has been fixed.
[SDCOMP-23761]At -O3 -Otime, an expression of the form (c/-a), where c has the value INT_MIN and a has the value INT_MAX, could be wrongly transformed leading to an arithmetic overflow. This has been fixed.
[SDCOMP-23760]At -O3 -Otime, when unrolling a nested loop with constant loop limits and increments which read from a global variable, the compiler could generate code that failed to reproduce the effects of all loop iterations. This has been fixed.
[SDCOMP-23685]At -O2 and above, the compiler could optimize certain expressions involving two consecutive loads from the same volatile location as though the two loads were guaranteed to return the same value. This has been fixed.
[SDCOMP-23642]At -O2 and above, if an lvalue was conditionally set to a constant and subsequently shifted by another constant when being compared against a value known to be a constant, then the comparison was incorrectly performed as though the shift was not present. This has been fixed.
[SDCOMP-23582]At -O1 and above, if an element of a string literal was accessed through an unsigned char pointer and the element had the top bit set then its value
would be wrongly sign-extended. This has been fixed.
[SDCOMP-23551]At -O1 -Otime and above, compiling a conditional expression ((e%M)? T : F) with constant M, T and F would generate an internal fault if the expression was nested twice in the condition of an expression or once in the condition of an if statement. For example:
```
((((e%M)? T : F)? T1 : F1)? T2 : F2)
```
or:
```
if ((((e%M)? T : F)? T1 : F1){ .. }
```
This has been fixed.
[SDCOMP-23494]The compiler could report internal fault 0x87ecef when compiling an anonymous namespace that contained a type definition that needed a virtual table. This has been fixed.
[SDCOMP-23386]At -O3 -Otime, when the condition of an if statement contained an expression A[c1][c2], where A was an array of struct elements declared with a constant initializer, and c1 and c2 were constants, internal fault 0x2d15b6 could occur. This has been fixed.

Assembler (armasm)

[SDCOMP-23935]When using --cpreproc with two or more separate -I options, the assembler would fail to correctly pass the include directories to the compiler, resulting in error A1905U. This has been fixed.

Enhancements in ARM Compiler 5.04

Compiler (armcc)

[SDCOMP-23470]The data flow analysis diagnostic C4017: <entity> may be used before being set is now suppressed by default at all optimization levels. It can be enabled using --diag_warning=C4017.
[SDCOMP-22700]Options have been added for controlling the generation of literal pools and branch tables. Disabling literal pools and branch tables will avoid the compiler placing data in code sections, either by placing data in data sections or synthesizing constants in line. The default is to generate all the literal pools and branch tables. The new options are:
- --integer_literal_pools / --no_integer_literal_pools
- --float_literal_pools / --no_float_literal_pools
- --string_literal_pools / --no_string_literal_pools
- --branch_tables / --no_branch_tables.

Libraries

[SDCOMP-22595]The library functions __rt_sdiv32by16, __rt_udiv32by16 and __rt_sdiv64by32 have been deprecated.

General enhancements

[SDCOMP-23478]Implemented --debug_info=line_inlining_extensions as a compiler option. Within the line table, entry to an inlined function is indicated by DW_LNE_lo_user and exit from an inlined function is indicated by DW_LNE_lo_user+1.
[SDCOMP-23370]The ARM Compiler now supports the invocation of a sub-process when the current working directory is a Windows UNC path. The sub-process invocations affected by this change are:
- armcc calling armlink or armasm
- armasm calling armcc
- armlink calling armcc
[SDCOMP-23344]ARM Compiler 5.04 has changed the version strings reported by armar, armasm, armcc, armlink, and fromelf. These now display three-part messages of the form:
Product: ARM Compiler 5.04
Component: ARM Compiler 5.04
Tool: armcc [5040027]
The Product string reflects the product that the toolchain is a component of, for example DS-5 or ARM Compiler 5.04. The Component string reflects the version of ARM Compiler that is being used. Tool provides a unique identifier for the specific tool being used.
[SDCOMP-23284]Support for execute-only memory regions when building for ARMv7-M has been added to ARM Compiler 5.04. For more information on using this functionality, please see the ARM Compiler documentation.
[SDCOMP-23283]ARM Compiler 5.04 adds support for:
- Windows 8 (64-bit)
Support has been deprecated for:
- Ubuntu 10.04 LTS (32-bit) platform.
Cygwin support (32-bit platforms only), moves to Cygwin version 1.7.25.
[SDCOMP-22083]The future ARM Compiler 5.05 feature release will deprecate support for the following host platforms:
- Windows Server 2003 (32-bit)
- Red Hat Enterprise Linux 5 (32-bit and 64-bit)

Defect fixes in ARM Compiler 5.04

Compiler (armcc)

[SDCOMP-23465]At -O3 -Otime, the compiler could replace simple array initialization sequences with memset and then expand this inline in a way that caused incorrect code generation. This has been fixed.
[SDCOMP-23413]At -O3 -Otime, in some circ*mstances the compiler could unroll a loop but miscalculate changes to loop variables, leading to incorrect code being generated. This has been fixed.
[SDCOMP-23317]When compiling with --multifile, the compiler could crash if the second or later input file used numeric labels in inline assembly. This has been fixed.
[SDCOMP-23297]If a local, non-static object was initialized with a constructor taking the result of calling new, using the format T obj(new S()), and control passed out of the object's scope because of a thrown exception, then the object's destructor would not be called. This has been fixed.
[SDCOMP-23265]At -O3 -Otime, a loop with a constant but odd number of iterations would be unrolled twice with a single iteration lifted out of the loop. The compiler would fail to preserve the dependencies in the sequence lifted out of the loop, leading to incorrect results. This has been fixed.
[SDCOMP-23264]At -O3 -Otime, a loop initializing an array from the loop counter followed by a loop that used the array would be combined into a single loop. Because of incorrect changes to the array references, the new loop was not equivalent to the original code. This has been fixed.
[SDCOMP-23263]When compiling with --multifile, the compiler could crash if the second or later input file used a NOP instruction in inline assembly. This has been fixed.
[SDCOMP-23237]At -O0 only, a conditional expression that tests bit 31 of a 64-bit integer could be miscompiled, leading to incorrect results. This has been fixed.
[SDCOMP-23136]If there was a write to a bitfield (for which the compiler has to generate a read-modify-write sequence) that occurred after a call to memset() in an if-else block, the compiler could move the read of the bitfield container to before the memset operation, resulting in an incorrect value being written to the bitfield container. This has been fixed.
[SDCOMP-23039]Objects that use section flags which are not defined by the ABI are no longer marked as ABI-compliant.
[SDCOMP-23023]When compiling with --multifile, the compiler could crash if the second or later input file used instructions with more than one operand in inline assembly. This has been fixed.
[SDCOMP-23016]At -O3 -Otime, when compiling code containing two distinct loops operating on an array of union type, where the first loop is writing to it, and the second is reading from it, the compiler would merge the loops and move the reads before the writes. This resulted in incorrect behavior at run-time. This has been fixed.
[SDCOMP-23015]At -O3 -Otime, the compiler could unroll a loop with a small, constant limit but fail to detect all uses of the iteration variable. This behaviour could lead to incorrect code being generated. This has been fixed.
[SDCOMP-23013]At -O3 -Otime, if a local integer variable was accessed and incremented through a pointer within a loop, and the accessed values were summed, the compiler could generate incorrect code. This has been fixed.
[SDCOMP-23011]At -O3 -Otime, an invalid transformation could be applied to an expression of the form (INT_MIN / -INT_MAX) that appeared in the condition of an if statement. This has been fixed.
[SDCOMP-23010]At -O3 -Otime, the compiler could miscalculate an integer expression involving large integer constants when trying to simplify the condition in an if statement. This has been fixed.
[SDCOMP-23009]At -O3 -Otime, the optimization of a loop involving variables of char or short type could wrongly promote the variables to type int, leading to unexpected results. This has been fixed.
[SDCOMP-23007]At -O3 -Otime, the compiler could miscalculate the comparison of a constant against INT_MIN, leading to incorrect results. This has been fixed.
[SDCOMP-23006]At -O3 -Otime, in a loop that contains a write to a variable that is also read through a pointer, the wrong value could be read. This has been fixed.
[SDCOMP-23005]At -O3 -Otime, when unrolling simple, nested loops with assignments to array elements, the compiler could incorrectly remove some of the assignments. This has been fixed.
[SDCOMP-23004]At -O3 -Otime, a loop that contains a conditional assignment, which also assigns a constant to a variable in its initialization, could cause the compiler to generate incorrect code. This has been fixed.
[SDCOMP-23003]At -O3 -Otime, a for-loop beginning at INT_MIN could be incorrectly unrolled into a conditional statement guarded by an expression that would overflow. This has been fixed.
[SDCOMP-23002]At -O1 and above, a call to memset on a small, global array could be expanded inline in a way that caused invalid code analysis, leading to incorrect code being generated. This has been fixed.
[SDCOMP-23001]At -O3 -Otime, if a multi-dimensional array was initialized with a sparse list, the compiler could wrongly make assumptions about the value of the uninitialized elements. This has been fixed.
[SDCOMP-22995]At -O3 -Otime, the compiler could fail to terminate when compiling a switch statement with an empty body. This has been fixed.
[SDCOMP-22994]When compiling under Windows at -O3 -Otime, the compiler could use the wrong value for INT_MIN in some integer expressions. This would typically happen when simplifying conditionals or transforming loops when the expressions involved integer limits. This has been fixed.
[SDCOMP-22993]At -O3 -Otime, if a pointer to a loop counter variable was dereferenced after the loop, the compiler could generate code that incorrectly returned the value of the counter before the loop. This has been fixed.
[SDCOMP-22992]When compiling under Windows at -O3 -Otime, some arithmetic operations involving INT_MIN could cause the compiler to stop with an integer overflow fault. This has been fixed.
[SDCOMP-22884]The compiler could incorrectly transform code that stores the address of a struct to a member of that struct, resulting in code that stores the address of the member. This has been fixed.
[SDCOMP-22879]At -O3 -Otime, the compiler could ignore the volatile qualifier on a field of a struct or union. This issue would only occur if all accesses were indirect, such as by reading the struct or union as a single object. This has been fixed.
[SDCOMP-22770]The compiler could incorrectly translate x <= y where x was an int and the difference between x and y was greater than the largest non-negative int. This has been fixed.
[SDCOMP-22760]Code generated to access a bitfield with base type long long could sometimes produce a corrupted value or access the wrong memory location. This has been fixed.
[SDCOMP-22712]When a long long or double was passed as an argument to a function, such that its stack offset exceeded the maximum LDR immediate offset for the target instruction set, the value of that argument could be incorrect. This has been fixed.
[SDCOMP-22538]At -O1 and above, when a function with restrict pointer arguments was inlined this could cause incorrect code generation in the inlined-into function. This has been fixed.
[SDCOMP-22511]In certain situations assigning to the dereferenced pointer result of an inlined function at -O3 -Otime could cause internal fault 0x87ecef. This has been fixed.
[SDCOMP-22486]At -O3 -Otime --vectorize, the compiler could incorrectly choose a vectorized version of the code when copying char data to short data via overlapping pointers. Additionally, the compiler could incorrectly transform a decrementing loop into an incrementing one in the non-vectorized version of the code. Both issues have been fixed.
[SDCOMP-22471]The compiler could generate inefficient code when assigning to a struct containing at least one volatile member. This has been fixed. When appropriate, the compiler now uses memcpy for non-volatile members.
[SDCOMP-22376]The function attribute __attribute__((weakref)) was not marking references to the aliased function as weak. This has been fixed.
[SDCOMP-22337]The compiler could report internal fault 0xe35e83 when compiling C++ code with exceptions enabled at -O3. The cause of this internal fault has been fixed.
[SDCOMP-22321]At -O3 -Otime, when optimizing a loop involving a floating point calculation, the compiler could generate an intermediate variable of type int. This variable is used to store a floating point value, leading to an incorrect calculation due to float to int type conversion truncating the value and discarding the fractional part. This has been fixed.
[SDCOMP-22301]The compiler will now report error 3094 if __stack_chk_guard is wrongly defined as code rather than data, and error 3095 if __stack_chk_fail is wrongly defined as data rather than code.
[SDCOMP-19892]The option --no_data_reorder did not work correctly on files containing a mixture of initialized and uninitialized file-scope variables. This has been fixed.
[SDCOMP-18315]The compiler could generate inefficient code when assigning to a class containing at least one volatile member. This has been fixed. When appropriate, the compiler now uses memcpy for non-volatile members.
[SDCOMP-11964]In some circ*mstances, a report of error 137: expression must be a modifiable lvalue would wrongly be accompanied by a report of warning 1441-D: nonstandard cast on lvalue. This has been fixed.

Assembler (armasm)

[SDCOMP-22554]The assembler would previously not create IT blocks for conditional MSR instructions on M-profile cores, and would incorrectly generate an unconditional instruction. This has been fixed.

Linker (armlink)

[SDCOMP-22938]When an execution region containing compressed RW data has the same load and execution address, the linker must decompress the compressed RW data to a temporary area of memory before overwriting the compressed RW data. The linker no longer uses memory described by execution regions with both EMPTY and UNINIT attributes for this purpose.
[SDCOMP-22483]The linker will no longer produce internal fault 0x3d9eed when processing debug information relating to an unused __thread variable.
[SDCOMP-22246]The following issues with the --feedback_image option have been fixed:
- When using none or noerrors:
  - The linker would crash when the address of a FIXED region overlapped another
  - Errors relating to the .ANY scatterfile selector were not downgraded (L6406E, L6407E)
  - Errors relating to possible scatterloading corruption were not downgraded (L6788E)
  - Errors resulting from ScatterAssert expressions were not downgraded (L6388E).
- When using simple:
  - bitband regions were not supported and resulted in error L6191E
  - __at sections would result in an error if the address overlapped with an address already in the default scatter-file.
[SDCOMP-22145]The linker will no longer produce virtual function elimination errors when trying to link an invalid C++ program with missing symbols. The linker will now produce errors about the missing symbols.
[SDCOMP-20307]When using --paged the scatter file FILL and PADVALUE attributes incorrectly behave as though EMPTY ZEROPAD had been specified. This has been fixed.
[SDCOMP-19471]The linker would not define all necessary linker defined symbols when linking with --feedback_image=simple, which could lead to error L6218E. This has been fixed.
[SDCOMP-18236]The linker would compute the results of LoadBase and LoadLimit functions in ScatterAssert expressions relative to the execution region base rather than the load region base. This could result in missing or spurious assertion errors. This has been fixed.
[SDCOMP-17693]If the $Sub and $Super mechanism was used to write a wrapper for a C library function for which there are multiple implementations, the linker could select the wrong variant of that function from the library for the $Super version. The list of affected functions is long, but includes the multithreading and realtime heap versions of malloc, and the multitheading versions of any of the high-level I/O functions. This has been fixed.
[SDCOMP-17034]The linker could break section placement ordering rules by inserting a veneer after a zero-sized data section. This has been fixed.
[SDCOMP-13661]When an OVERLAY region was followed by two incorrectly overlapping execution regions, the linker failed to report error L6221E. This has been fixed.
[SDCOMP-11735]The definition of Image$$ execution region symbols has changed. For an execution region called ER the symbols Image$$ER$$Base, Image$$ER$$RO$$Base, Image$$ER$$RW$$Base, Image$$ER$$ZI$$Base, Image$$ER$$Limit, Image$$ER$$RO$$Limit, Image$$ER$$RW$$Limit, and Image$$ER$$ZI$$Limit now include padding inserted by the linker to align the Base and Limit of the RO, RW and ZI section representing the execution region in the ELF file. This change has been made so that the behavior of the Image$$ symbols with respect to padding matches the Load$$ symbols.
The behavior of --no_legacyalign has been fixed. All ELF sections are now compliant with the section alignment requirements of the ELF specification. Previously only the base and file offset of the first ELF section representing the execution region was aligned to the execution region alignment.
The behavior of the scatter file ALIGN keyword when used with --no_legacyalign has changed. The alignment of the execution region is the value defined by the ALIGN directive, or the input section alignment requirement if greater. Previously the value defined by the ALIGN directive would be used instead of the input section alignment.