#pragma push/pop
, the diagnostic message cannot be saved.std::stable_sort
function is executed, delete
with NULL
specified and new
with 0 Bytes
specified are called.for
statement with -Otime -O3
optimization.-O3 -Otime
combination.--gnu
option is specified when using a STL algorithm, a warning is issued.-Otime -O3
optimization, invalid values are written in the array with the for
loop.nn::math::Matrix
, the arguments are sometimes corrupted.introsort_loop
function is used, a large volume of recursive calls occurs.for
loops that use unsigned integer decrements sometimes enter infinite loops.-O3
and -Otime
options, invalid values are sometimes used with the comparison expression.-Otime
and -O3
optimizations, the final portion of the array is passed and an invalid read operation occurs.-Otime -O3
optimization, invalid parameters are passed with a function call to inside the unnamed namespace.-Otime -O3
optimization, sometimes arrays are set with invalid values.-O2
or higher optimization, sometimes calculations no longer perform correctly.-Otime -O3
optimization, sometimes calculations are not performed in the correct order.-Otime -O3
optimization, an invalid variable initialization is sometimes performed.--gnu
, the overload functions in the function templates are not resolved to be argument-dependent.NULL
when -O3 -Otime
optimization is used.-O2
or higher optimization, an invalid offset is sometimes used to write to a structure member variable.-Otime -O3
optimization, sometimes code with invalid loops is generated.error
is specified for --diag_suppress
.error
is specified for --diag_warning
alloca
are made into inline functions with __forceinline
.-Otime -O3
options, sometimes the function that initializes variables is called twice.-Otime -O3
options, sometimes the function that initializes variables is called twice in the loop.std::vector::operator=
is reduced, an invalid size is passed to the deallocate
member of the Allocator
class.
1.
Symptom Even when optimization is enabled, optimization of the command order is not enabled. Cause In some cases, the pre-scheduler optimization does not operate as expected. Versions That Have This Problem - ARMCC 4.1 b576 and earlier - RVCT 4.0 Workaround None. State of Support - Fixed in ARMCC 4.1 b576. - No revision plans for RVCT 4.0. |
2.
Symptom Even when using Cause
This bug originated in the compiler.The state where Versions That Have This Problem - ARMCC 4.1 - RVCT 4.0 Workaround None. State of Support - Fixed in ARMCC 5.01 b34.- No revision plans for ARMCC 4.1 and RVCT 4.0. |
3.
Symptom
When the Cause There is a bug in the Rogue Wave C++ library used with RVCT. Versions That Have This Problem - ARMCC 4.1 - RVCT 4.0 Workaround None. State of Support - Fixed in ARMCC 4.1 b918.- No revision plans for RVCT 4.0. |
4.
Symptom After updating ARMCC 4.1, you cannot have mixed operators in vector mode.For example: vfpassert vector<3> fmuls s16<3>, s8<3>, s0<> vfpassert scalar Error: error A1422: This combination of vector and scalar operands is not allowedAlso, if the fmuls line is changed as shown below, a different error occurs.
fmuls s16<3>, s8<3>, s0<1> Error: error A1416: Vector length does not match current vector length 3 Cause There is a bug in Versions That Have This Problem - ARMCC 4.1 Workaround None. State of Support - Fixed in ARMCC 4.1 b909. |
5.
Symptom With a -- struct Vec { Vec() : x(0), y(0) {} int x, y; }; class Array { public: Array(); Vec* get() { return mArray; } private: Vec mArray[ NUM ]; }; Array::Array() { for( int i = 0; i < NUM; ++i ) { mArray[i].x = i; mArray[i].y = i; } } void test() { Array* a = new Array; Vec* v = a->get(); for( int i = 0; i <= NUM-1; ++i ) { a->get()[i].y = 0; // The unhandled exception happens here. } } -- Cause We are investigating the cause, but this symptom does not occur after ARMCC 4.1 b640. Versions That Have This Problem - ARMCC 4.1 b640 and earlier versions - RVCT 4.0 Workaround
Specify -- #pragma push #pragma Ospace void test() { ... } #pragma pop -- State of Support - This problem does not occur after ARMCC 4.1 b640.- No revision plans for RVCT 4.0. |
6.
Symptom When using a precompile header in ARMCC 4.1, internal faults sometimes occur. Cause There is a bug in the front end portion of the compiler. Versions That Have This Problem - ARMCC 4.1 Workaround
Because there is no effective workaround, do the following so that the precompile header is not read.Note: Add the following pragma to the start of the source code for the side reusing the PCH ( -- #pragma hdrstop #include "test.h" // Precompiled header. -- State of Support - Fixed in ARMCC 4.1 b911. |
7.
Symptom There is a bug in RVCT 4.0 in the loop optimization process enabled by the -- #include<nw/gfx.h> using namespace nw::math; static MTX34 OptErrSub2() { return MTX34::Identity(); } inline MTX34 operator*(const MTX34 &lhs, const MTX34 &rhs) { MTX34 res; MTX34Mult (&res, &lhs, &rhs); return res; } inline f32 OptErrSub1() { MTX34 mf = OptErrSub2()*OptErrSub2(); return mf.a[0]; } f32 OptErrTest() { f32 res; s32 ok = 1; do { res = OptErrSub1(); } while( ok == 0 ); return res; } -- Cause
With this code, in the Versions That Have This Problem - RVCT 4.0 Workaround Because there are no plans to update RVCT 4.0, use the following. -- #pragma push #pragma Ospace f32 OptErrTest() { ・・・ } #pragma pop -- State of Support No revision plans for RVCT 4.0. |
8.
Symptom "Warning: C3007E" is displayed at build time with RVCT 4.0. Cause This problem was a bug in RVCT 4.0.If this error does not occur with ARMCC 4.1, there is no problem with the generated code. Versions That Have This Problem - RVCT 4.0 Workaround
- Add #pragma push #pragma O0 // Relevant function (function for which warning 3007 is issued). #pragma pop State of Support No revision plans for RVCT 4.0. |
9.
Symptom When the Cause RVCT 4.0 had a bug that displayed inappropriate warnings. Versions That Have This Problem - RVCT 4.0 Workaround None. State of Support No revision plans for RVCT 4.0. |
10.
Symptom The Cause This bug originated in the compiler.During loop optimization, the compiler improperly handles the calculation conditional expression for the absolute value of the difference between two unsigned variables. This bug occurs for code such as the following. -- unsigned foo(unsigned *curr, unsigned *last) { unsigned tot = 0; for(int i = 0; i < 10; ++i) { unsigned diff = (curr[i] >= last[i]) ? (curr[i] - last[i]) : (last[i] - curr[i]); tot += diff; } return tot; } -- Versions That Have This Problem - ARMCC 4.1 b619 and earlier versions - RVCT 4.0 Workaround Lower the optimization level for the relevant portion. State of Support - Fixed in ARMCC 4.1 b619.- No revision plans for RVCT 4.0. |
11.
Symptom With the Cause
There is a bug in the loop optimization enabled with -- static __declspec(noinline) void test(u32 seed) { u32 x = (seed | 1U) & 0xFFFFFFFFU; u32 *s = &sState[1]; int j; for(*s++=x, j=N; --j; *s++ = (x*=69069U) & 0xFFFFFFFFU) { ; } } -- Versions That Have This Problem - ARMCC 4.1 b654 and earlier - RVCT 4.0 Workaround
You can avoid this bug by specifying -- #pragma push #pragma Ospace static __declspec(noinline) void test(u32 seed) { ... } #pragma pop -- State of Support - Fixed in ARMCC 4.1 b654.- No revision plans for RVCT 4.0. |
12.
Symptom When calling a function that uses Cause
This bug originated in the compiler.With a call to a function using -- #include<nn.h> using nn::math::Matrix34; Matrix34 func(const Matrix34& in) { Matrix34 out(0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f); // The out address and in address are the same. in.Report(); // in is already corrupted. out.f._00 = in.f._00; // A correct result cannot be obtained. return out; } void nnMain(void) { Matrix34 a(1.0f, 2.0f, 3.0f, 4.0f, 5.0f, 6.0f, 7.0f, 8.0f, 9.0f, 1.0f, 2.0f, 3.0f); a = func(a); a.Report(); return; } -- Versions That Have This Problem - ARMCC 4.1 b713 and earlier versions - RVCT 4.0 Workaround
You can avoid this problem by storing the -- //a = func(a); MTX34 tmp = func(a); a=tmp; -- State of Support - Fixed in ARMCC 4.1 b713. - No revision plans for RVCT 4.0. |
13.
Symptom The results of a shift calculation differ according to the optimization level. When the following code is executed, the result of a Debug build differs from that of a Release build. #include <stdio.h> #include <nn/os.h> #include <nn/dbg.h> extern "C" void nnMain() { s16 buff[ 2 ] = { 0xffff, 0x00ff }; u32 data = (u32)( buff[ 0 ] | buff[ 1 ] << 16 ); NN_LOG( "%08x\n", data ); while(1){} } Results ・ For Debug: ffffffff ・ For Release: 00ffffff Cause
There is a bug in the rotation optimization that is enabled when Versions That Have This Problem - ARMCC 4.1 b791 and earlier versions. Workaround Change the optimization level in the function in the relevant code. #pragma push #if __OPTIMISE_LEVEL >= 2 #pragma O1 #endif extern "C" void nnMain() { s16 buff[ 2 ] = { 0xffff, 0x00ff }; u32 data = (u32)( buff[ 0 ] | buff[ 1 ] << 16 ); NN_LOG( "%08x\n", data ); while(1){} } #pragma pop State of Support - Fixed in ARMCC 4.1 b791. |
14.
Symptom When the Cause
There is a bug in the Versions That Have This Problem - ARMCC 4.1 - RVCT 4.0 Workaround
You can avoid this problem by inserting the following code before the State of Support - Fixed in ARMCC 4.1 b907.- No revision plans for RVCT 4.0. |
15.
Symptom When the optimization level is raised, writing to unintentional addresses occurs.
When the following code is built with an optimization level of void arm11_test(void) { unsigned char dst_obj[64 * 4]; unsigned char ref_obj[64 * 4]; unsigned char *dst; unsigned char *ref; unsigned long rx = 1; unsigned long v0, v1, v2, v3, v4; signed long ref_skip; signed long i; dst = dst_obj; ref = ref_obj; ref_skip = rx; for (i = 0; i < 3; i++) { v0 = *(unsigned long *)(ref + 0); v1 = *(unsigned long *)(ref + 1); v2 = *(unsigned long *)(ref + 2); v3 = *(unsigned long *)(ref + 3); v4 = (unsigned long)*( ref + 4); v0 = (unsigned long)(((v0) >> 1) | ((v1) << 1)); v1 = (unsigned long)(((v1) >> 1) | ((v2) << 1)); *(unsigned long *)(dst) = v0; *(unsigned long *)(dst + 4) = v1; v2 = (unsigned long)(((v2) >> 1) | ((v3) << 1)); v4 = (unsigned long)(((v3) >> 1) | ((v4) << 1)); // The expectation is that data will be written to an address 64 bytes away from dst, // but instead data is stored at an address 72 bytes away. *(unsigned long *)(dst + 64) = v2; *(unsigned long *)(dst + 64 + 4) = v4; ref += ref_skip; dst += 8; } } Cause There was a bug in the process for the compiler to optimize LDM/STM instructions. Versions That Have This Problem - ARMCC 4.1 b791 and earlier versions. Workaround
Because this optimization is enabled with #pragma push #pragma O1 void arm11_test(void) { // Omitted. } #pragma pop State of Support - Fixed in ARMCC 4.1 b791. |
16.
Symptom
When compiling with Cause
There was a bug in the compiler. This problem occurs with code similar to the following. ---------------------------- for( unsigned int i = 100; i != (unsigned int)-1 ; --i ) { ... } ---------------------------- Versions That Have This Problem - ARMCC 4.1 b619 and earlier versions - RVCT 4.0 Workaround
You can avoid this problem by replacing with an increment loop and changing the code so that no comparison to State of Support
- Fixed in ARMCC 4.1 b713. |
17.
Symptom Signed value and unsigned value conversions cannot be performed at times.
When RVCT 4.0/ARMCC 4.1 is used and code similar to the following is compiled, u16 uVal = 0x999c; s16 sVal = *(s16*)&uVal; int intVal = (int)sVal; Note: Even though the value for Cause This bug originated in the compiler. Versions That Have This Problem - ARMCC 4.1 b713 and earlier versions - RVCT 4.0 Workaround
Try using a method to explicitly have sign extensions by either setting u16 uVal = 0x999c; s32 tmp = *(s16*)&uVal; s16 sVal = (s16)tmp; int intVal = (int)sVal; State of Support
- Fixed in ARMCC 4.1 b713. |
18.
Symptom When compiling functions that use inline keywords with the Cause
There was a bug in the compiler Versions That Have This Problem - RVCT 4.0 Workaround
There are no plans to revise RVCT 4.0, so add the following #pragma push #pragma Ono_cse float hogehoge(unsigned int var1) { ・・・ } #pragma pop State of Support - No revision plans for RVCT 4.0. |
19.
Symptom With the Cause
With This bug occurs for code such as the following. int test(int* input, int length) { int r = 0; for (int i = 0; i < length; i++) { r += *input++; } return r; }When the end of a memory loop is used in the array region, an access violation sometimes occurred. Versions That Have This Problem - ARMCC 4.1 b640 and earlier versions - RVCT 4.0 Workaround
You can avoid this problem by specifying #pragma push #pragma Ospace int test(int* input, int length) { ... } #pragma pop State of Support - Fixed in ARMCC 4.1 b640.- No revision plans for RVCT 4.0. |
20.
Symptom "Warning 997 virtual function override intended?" is suppressed.
When you include Cause
This warning is suppressed in Versions That Have This Problem - ARMCC 4.1 - RVCT 4.0 Workaround
#include <nn/fs.h> After the preceding code, if the following code is written, #pragma diag_warning 997 the warning can be displayed. State of Support - This bug was fixed in CTR-SDK 5.0. |
21.
Symptom With Cause
There was a bug in the compiler. namespace { volatile int& s_Reg = *reinterpret_cast(0x00100000); void Test0(int x) { s_Reg = x; } } void Test1() { Test0(0x1234); int tmp; __asm { mrs tmp, cpsr } } void Test2() { Test0(0x5678); } Versions That Have This Problem - ARMCC 4.1 b640 and earlier versions - RVCT 4.0 Workaround
Because there are no plans to revise RVCT4.0, you can avoid this bug by specifying namespace { volatile int& s_Reg = *reinterpret_cast(0x00100000); #pragma push #pragma Ospace void Test0(int x) { s_Reg = x; } #pragma pop State of Support - Fixed in ARMCC 4.1 b698.- No revision plans for RVCT 4.0. |
22.
Symptom Warnings such as #634-D and #631-D are displayed. Cause
The main reason this warning is issued is that the randomization of the address space layout (ASLR) on the host size is enabled, and this may be the problem. Versions That Have This Problem - ARMCC 4.1/5.x - RVCT 4.0 Workaround Disable security software during builds. State of Support - No plans for revision in the near future. |
23.
Symptom Internal errors occur with the template to generate zero-size arrays.
If you instantiate a template with code like the following,
template Cause There is a bug in the front end of the compiler. Versions That Have This Problem - ARMCC 4.1/5.x - RVCT 4.0 Workaround None. State of Support - No fixes are planned for ARMCC 4.1/5.x or RVCT 4.0. |
24.
Symptom The compiler generates an internal fault when precompiled headers are used. Cause This bug originated in the compiler. Versions That Have This Problem - ARMCC 4.1 Workaround
Use State of Support - Fixed in ARMCC 4.1 b911. |
25.
Symptom With Cause
This bug involves invalid handling of type information when optimization is enabled with This bug occurs for code such as the following. struct Element { float x, y, z, u0, v0, u1, v1; }; #define DIVISOR 5 void SetData(Element* elements, f32 v0) { Element* e = elements; for (int t = 0; t < DIVISOR + 1; t++) { f32 v = v0 * t; for (int s = 0; s < DIVISOR + 1; s++) { e++->v0 = v; } } } Versions That Have This Problem - ARMCC 4.1 b1133 and earlier versions. Workaround Use one of the following workarounds.
1) Specify #pragma push #pragma O2 void SetData(Element* elements, float v0) { // Omitted. } #pragma pop
2) Perform an explicit type conversion. (Cast type float v = v0 * (float)t; State of Support - Fixed in ARMCC 4.1 b1247. |
26.
Symptom With Cause
This bug is related to This bug occurs for code such as the following. struct Test { unsigned short _n; }; inline static void add(Test* __restrict p) { ++p->_n; } inline static void run(Test* __restrict p) { add( p ); ++p->_n; p->_n += p->_n; } Test gTest; extern "C" void nnMain(void) { run( &gTest ); nn::dbg::detail::Printf( "\nResult: N = %04x\n", gTest._n ); for( ;; ); } Versions That Have This Problem - ARMCC 4.1 b1133 and earlier versions. Workaround
As a workaround to this bug, use the State of Support - Fixed in ARMCC 4.1 b1247. |
27.
Symptom With Cause
There is a bug in the optimization enabled with the This bug occurs for code such as the following. #pragma no_inline class DMY{}; void* testSub(DMY, const char* a, size_t* size) { *size = 160; return (void*)a; } void test() { size_t size; void* p = testSub(DMY(), "hoge", &size); int n = size/8; printf("n: %d\n", n); if (p==NULL) return; printf("p: %s\n", p); } Versions That Have This Problem - ARMCC 4.1 b1133 and earlier versions. Workaround Use one of the following workarounds.
1) Change the optimization level for the function, and use a combination other than #pragma push #pragma Ospace void test() { // Omitted. } #pragma pop
2) Add the private compiler option State of Support - Fixed in ARMCC 4.1 b1247. |
28.
Symptom With Cause
This bug occurs in the loop optimization that is enabled with This bug occurs for code such as the following. u32 foo() { // Omitted. case CASE_ooo: for (j = 0, i = 0; j < 2; j++) { // Omitted. for (k = 8; k--; i++) { p->m_bar[i] = hoge; // Omitted. } } // Omitted. }The index was not being created correctly for the operation that stores values in p->m_bar[i] , which led to invalid results.
Versions That Have This Problem - ARMCC 4.1 b1247 and earlier versions. - ARMCC 5.03 b102 and earlier versions. Workaround Use one of the following workarounds.
1) Change the optimization level for the function, and use a combination other than #pragma push #pragma O2 u32 foo() { // Omitted. } #pragma pop 2) Handle variable initialization outside the loop. case CASE_ooo: i = 0; for (j = 0; j < 2; j++) { State of Support
- Fixed in ARMCC 4.1 b1307. |
29.
Symptom After updating to ARMCC 5.x, when specifying Cause This problem is caused by the GCC bug emulation of the GNU compatibility mode in the front end used in ARMCC 5.x. This bug occurs for code such as the following. templateThe bar(const Y*, const X*) function calls the foo(const U* u) template. This call strips the const operator from the u argument (because the const_cast operator is used), and calls the foo function.
In the C++ standards, the compiler considers the foo function name to be visible. Accordingly, it starts checking the argument dependencies of other overload functions and searches the foo(U * U) function template.Because GCC does not perform argument-dependendent lookups, it uses foo(const U* u) rather than foo(U *u) . This bug originated in GCC and was fixed in 4.4.4, but the ARMCC 5.x GNU compatibility mode emulates the incorrect GCC functionality.
Versions That Have This Problem - ARMCC 5.x Workaround None. State of Support To be determined. |
30.
Symptom After updating to ARMCC 4.1 b1247, pointers to static data are sometimes set to Cause
This bug occurs in optimization that is enabled with This bug occurs for code such as the following. class Hoge : HogeBase { public : static const char* cHoge_A[]; static const char* cHoge_B[]; private : void foo(bool b); }; const char* Hoge::cHoge_A[] = { (Omitted) }; const char* Hoge::cHoge_B[] = { (Omitted) }; void Hoge::foo(bool b) { Index i = GetIndex(); const char* pName = b ? cHoge_A[i] : cHoge_B[i]; (Omitted) }An uninitialized value was loaded into pName and NULL was set.
Versions That Have This Problem - ARMCC 4.1 b1247 Workaround Use one of the following workarounds.
1) Change the optimization level for the function, and use a combination other than #pragma push #pragma O2 void Hoge::foo(bool b) { (Omitted) } #pragma pop 2) Separate ternary operator and variable declarations. Before: const char* pName = b ? cHoge_A[i] : cHoge_B[i]; After: const char* pName; pName = b ? cHoge_A[i] : cHoge_B[i]; State of Support - Fixed in ARMCC 4.1 b1307. |
31.
Symptom After updating to ARMCC 5.x, the build fails when the path contains double-byte characters. Cause This bug is related to the compiler front end changed with ARMCC 5.0 or later. Versions That Have This Problem - ARMCC 5.x Workaround Avoid this problem by not using double-byte characters in the paths used with the build. State of Support - To be determined. |
32.
Symptom With Cause
This bug occurs in optimization that is enabled with This bug occurs for code such as the following. template< class Hoge1, class Hoge2, int n, typename Hoge3 > class Hoge { public: Hoge1* hoge1; Hoge2 hoge2a; Hoge2 hoge2b; Hoge3 hoge3[ n ]; public: Hoge() : hoge1( 0 ), hoge2a( ( Hoge2 )0 ), hoge2b( ( Hoge2 )0 ) { ::memset( hoge3, 0, sizeof( hoge3 ) ); } void Foo( Hoge1* h1, const Hoge3* h3, size_t len ) { hoge1 = h1; ::memcpy( hoge3, h3, sizeof( Hoge3 ) * n ); } };Code using the wrong offset during assignment to hoge1 was generated.
This bug is a problem with the optimization process in the final stages of the compilation and the details for the conditions of occurrence cannot be identified, but the following is known.
1) This bug occurs only for a Versions That Have This Problem - ARMCC 4.1 b1307 and earlier - ARMCC 5.04 b27 and earlier Workaround Use one of the following workarounds.
1) Change the optimization level of the appropriate function to #pragma push #pragma O1 void Bar::Bar() { (Omitted) hoge.Foo(this, p, n) (Omitted) } #pragma pop 2) Do not perform in-line expansion of the function that has this problem. Before: void Foo( Hoge1* h1, const Hoge3* h3, size_t len ) After: void Foo( Hoge1* h1, const Hoge3* h3, size_t len ) __attribute__((noinline)); State of Support - Fixed in ARMCC 4.1 b1440.- Fixed in ARMCC 5.04 b49. |
33.
Symptom After updating to ARMCC 5.x, the compiler sometimes shuts down improperly if the source uses an unnamed namespace. Cause This bug is in the ARMCC 5.x compiler front end. This bug occurs for code such as the following.
1) Combine the unnamed namespace and class Base { public: virtual ~Base() { } }; bool is_derived(Base *i_base); namespace { class Derived : public Base { }; } class AClass { public: static bool down_cast_test(Base *i_base) { Derived *d = dynamic_cast
2) Combine the unnamed namespace and the namespace { class Foo { public: Foo():_member(0) { } virtual ~Foo() { } protected: int _member; }; } namespace code { class Bar { Foo* _member; Bar() { _member = new Foo(); } virtual ~Bar() { delete _member; } }; } Versions That Have This Problem - ARMCC 5.04 b27 and earlier Workaround Use a named namespace for unnamed namespaces that have this problem. State of Support - Fixed in ARMCC 5.04 b49. |
34.
Symptom With Cause
This bug occurs in optimization that is enabled with This bug occurs for code such as the following. void foo( int first, int last ) { int sum = 0; int i, j; for( i = first, j = last; i <= last; j = i++ ) { sum += j; } NN_LOG( "sum = %d, i = %d, j = %d\n", sum, i, j ); }In this code, the value for the j variable is computed incorrectly, and the sum variable also takes on an invalid value.
Versions That Have This Problem - ARMCC 4.1 b1307 and earlier - ARMCC 5.04 b49 and earlier Workaround
Specify an optimization level other than #pragma push #pragma O2 void foo( int first, int last ) { // Omitted. } #pragma pop State of Support - Fixed in ARMCC 4.1 b1440.- Fixed in ARMCC 5.04 b82. |
35.
Symptom Sometimes fails to compile when Cause
Due to a bug, specifying Versions That Have This Problem - ARMCC 4.1 and 5.x Workaround
Work around this issue by directly specifying the message number of the error you want to hide, rather than specifying State of Support - No revision plans for ARMCC 4.1. - Support for ARMCC 5.x remains undecided. |
36.
Symptom Sometimes object files are not generated when Cause
Compile may end without outputting an object file if all errors that may be demoted to warnings are demoted using Versions That Have This Problem - ARMCC 4.1 - ARMCC 5.04 b82 and earlier Workaround
Work around this issue by directly specifying the message number of the error you want to demote to warnings, rather than specifying State of Support - No revision plans for ARMCC 4.1. - Fixed in ARMCC 5.04 b146. |
37.
Symptom An internal fault occurs when functions that use Cause
Functions that use Versions That Have This Problem - ARMCC 4.1 and 5.x Workaround
Work around this issue by not specifying State of Support - No revision plans for ARMCC 4.1. - Support for ARMCC 5.x remains undecided. |
38.
Symptom When optimizing with the Cause
This bug occurs in optimization that is enabled with the This bug occurs for code such as the following. struct Type1 { Type1(); }; struct Type2 { Type2(); }; struct Builder { Type1 method1(); Type2 method2(Type1); }; void broken(Builder *builder) { Type1 t1 = builder->method1(); // Called twice. const Type2 &t2 = builder->method2(t1); }In this code, method1 is called twice because the following generating factors are satisfied.
1: The result (t1 ) of some method (method1 ) is passed as the parameter of a different method (method2 )2: The result of this other method (method2 ) is assigned to a const reference (const Type2 &t2 ).
Versions That Have This Problem - ARMCC 4.1 b1247 through b1440 - ARMCC 5.04 b82 and earlier Workaround Use one of the following workarounds.
1) Change the optimization level for the function, and use a combination other than #pragma push #pragma Ospace void broken(Builder *builder) { Type1 t1 = builder->method1(); const Type2 &t2 = builder->method2(t1); } #pragma pop
2) Assign the result of Type2 t2 = builder->method2(t1); State of Support - Fixed in ARMCC 4.1 b1454. - Fixed in ARMCC 5.04 b146. |
39.
Symptom When optimizing with the Cause
This bug occurs in optimization that is enabled with the This bug occurs for code such as the following. struct X { X(); }; struct Y { Y(); }; X makeX(); bool proc(X, Y); void broken() { Y y; while (1) { X x = makeX(); // Called twice. bool result = proc(x, y); } }Also, it does not matter how proc is defined, or how x and y are supplied to proc . For example, the problem occurs even with the following code.
struct X { X(); }; struct Y { Y(); }; X makeX(); bool proc(void *, void*); void *convX(X); void *convY(Y); void broken() { Y y; while (1) { X x = makeX(); // Called twice. bool result = proc(convX(x), convY(y)); } }In this code, makeX is called twice because the following generating factors are satisfied.
1: Variable x and the scope of result are both inside the loop.2: Variable x is used to calculate result via a number of functions (proc ).3: The functions (proc ) take for their argument a different variable y with a scope outside of the loop.
Versions That Have This Problem - ARMCC 4.1 b1247 through b1440 Workaround Use one of the following workarounds.
1) Change the optimization level for the function, and use a combination other than #pragma push #pragma Ospace void broken() { { (Omitted) } #pragma pop
2) Move the declarations for variable void not_broken() { Y y; bool result; while (1) { X x = makeX(); result = proc(x, y); } } State of Support - Fixed in ARMCC 4.1 b1454. |
40.
Symptom When the size of the container that is assigned content by Cause This is a bug in the C++ library of ARMCC.
The symptom occurs when 1: source_vector.size() <= dest_vector.capacity() 2: dest_vector.size() >= source_vector.size() 3: dest_vector.capacity() != source_vector.size()
In this case, the Versions That Have This Problem - ARMCC 4.1 - ARMCC 5.04 b146 and earlier Workaround
As a workaround, make the revisions show below to the following part of the C++ library vector<_TypeT,_Allocator>::operator= (const vector<_TypeT,_Allocator>& __x)Before the revisions: else if (size() >= __x.size()) { iterator __it = copy (__x.begin (), __x.end (), begin ()); _C_destroy (__it, end ()); _C_end_of_storage = _C_finish = _C_start + __x.size(); }After the revisions: else if (size() >= __x.size()) { iterator __it = copy (__x.begin (), __x.end (), begin ()); _C_destroy (__it, end ()); _C_finish = _C_start + __x.size(); } State of Support - No revision plans for ARMCC 4.1. - Fixed in ARMCC 5.04 b166. |
41.
Symptom Compiler may improperly return a C9555E/C9558E error Cause When there is a file from before 1970/1/2 on the PC, a message similar to the following may be shown as an error at compile time. Error: C9558E: System clock tampering detected. License checkout will fail. Error: C9555E: License checkout for feature bsp_compiler5 with version 5.0201501 has been denied by Flex back-end. Error code: -1004This issue occurs with HostPCs with a Timezone of +1 to +12. Files before 1970/1/1 + Timezone are misidentified as invalid files, causing the error. Versions That Have This Problem - ARMCC4.1/5.x Workaround Correct the timestamp of files on the PC that are marked before 1970/1/2. Specifically, you can fix the files by running the following commands in Cygwin. $ cd /cygdrive/c $ find -type f -mtime +16425 -exec touch {} \; $ find -type f -atime +16425 -exec touch {} \;Usually, this is the C: drive. It is a different drive when the target drive (path) specified by the environment variables %SystemDrive% and %TEMP% are not C. Run on the target drive when the target drive is not the C: drive. Note that files in the Recycle Bin might also have been found by the check. If this action does not solve the problem, try emptying your Recycle Bin.
State of Support - No revision plans for ARMCC 4.1. - Planned to be fixed in a future release of ARMCC5.04. |
CONFIDENTIAL