Open Defects in Release

ID Summary State Reported In Release Target Release Workaround Release Notes
CODEGEN-4692 __delay_cycles intrinsic not available when building for Cortex-R5 Open ARM_18.1.1.LTS
CODEGEN-4668 Macro with temp label causes assembler to crash Open ARM_18.1.1.LTS
CODEGEN-4655 DWARF type incorrect for char function formal parameter Planned ARM_18.1.1.LTS Debugger displays the value of char argument passed to function incorrectly
CODEGEN-4621 Remove COFF global linker symbols from documentation for ELF-only targets Accepted ARM_18.1.1.LTS
CODEGEN-4498 When you link with --opt_level=4 and -mv7R5, linker complains about object file incompatibility Planned ARM_18.1.1.LTS Decrease optimization to -O3
CODEGEN-4346 MISRA 19.4 error fails to identify itself as MISRA diagnostic when problem is on the command line Accepted ARM_18.1.0.LTS
CODEGEN-4304 runtime failure on unaligned access (on some processor variants, not all) Open ARM_18.1.0.LTS The following code results in an unaligned access failure in the ARM simulator when compiled with: armcl -mv5e -me --float_support=vfpv2 #include <map> #include <stdio.h> int main(void) { std::map<int, char>::size_type n=9; std::map<int, char> g; char s[] = "contrived"; for (int i=0; i<n; i++) { char k = s[i]; std::pair<const int, char> p((int)k, k); g.insert(p); } int i00 = 0; std::map<int, char>::iterator it00 = g.begin(); printf("start for loop\n"); while (it00++ != g.end()) { printf("iteration %d\n", i00++); } printf("out of for loop\n"); return (1); }
CODEGEN-4298 Internal error when passing a temporary array of objects Accepted ARM_18.1.0.LTS The following example code exhibits an internal compiler error caused by passing a temporary C array as an argument to a function taking an rvalue reference to an array: struct S { int m; S(int i=1) : m(i) {} operator int() { return m; } int operator +(const S& r) { return m+r.m; } }; int f00(S (&&r)[3]) { return r[0] + r[1] + r[2]; } int main(void) { int g; S a(97), b(2), c(1); g = f00({a, b, c}); }
CODEGEN-4297 Cannot take the address of std::ctype<char>::table_size Open ARM_18.1.0.LTS This is a defect in the library. The table_size field is declared as having a constant value in the class definition, but there is no one definition for the field in the library. Taking the address of this field will result in a link-time error.
CODEGEN-4296 Undefined symbol isblank with -g or -ooff Open ARM_18.1.0.LTS The C99 function 'isblank' from ctype.h is provided as an inline definition when optimization is turned on, but there is no definition when optimization is turned off, leading to a link-time failure.
CODEGEN-4290 wstring runtime failure - likely bug in swprintf Open ARM_18.1.0.LTS
CODEGEN-4281 Unexpected type returned by bitset [] operator Open ARM_18.1.0.LTS The operator[] definition for std::bitset returns a const reference to an internally defined class type, rather than a bool as required by C++14 section 20.6.2
CODEGEN-4276 std::multimap::clear is not noexcept Open ARM_18.1.0.LTS The library does not declare std::multimap::clear as noexcept, which is required by C++14 section paragraph 2
CODEGEN-4275 std::num_get does not parse floating-point strings correctly Open ARM_18.1.0.LTS The C++ library locale helper, std::num_get, currently fails to correctly parser floating-point values in strings and streams. These calculations will always result in the default value of 0.0 for doubles, and 0.0f for floats. Please use the C library equivalents, such as sprintf, to perform such operations.
CODEGEN-4259 noexcept(typeid(d)) runtime fail on polymorphic class type Open ARM_18.1.0.LTS
CODEGEN-4258 deeply nested lambda functions hang the codegen Open ARM_18.1.0.LTS
CODEGEN-4250 regex_constants::ECMAScript not expected to be 0 Open ARM_18.1.0.LTS std::regex_constraints is a bitmask type, whose definition can be found in C++14 section Paragraph 3 of this definition states that all values in the bitmask must be nonzero, so that zero can be used as a special 'empty bitmask' value. The current implementation assigns std::regex_constraints::ECMAScript to 0, which goes against the definition.
CODEGEN-4248 armcl allows non-default arguments to be specified after default arguments Open ARM_18.1.0.LTS The following code should emit a syntax error due to the specification of a second, non-defaulted argument after a defaulted argument. However, the compiler will abort with an internal error. extern void foo(int, int); void f() { auto l = [](int i=1, int j) { foo(i, j); }; l(); }
CODEGEN-4247 Internal error when assigning default arguments to a parameter pack Open ARM_18.1.0.LTS The C++14 standard explicitly prohibits assigning default arguments to a template parameter pack. However, the compile accepts such code silently, and may result in an internal error during compilation. template <class... Types> void f(Types... args) { auto lm = [](Types... = args...) {}; lm(10); // internal error here } int main() { f(1, 23); return 0; }
CODEGEN-4246 armcl allows illegal attribute in friend declarations Open ARM_18.1.0.LTS
CODEGEN-4245 Multiple non-variables may be declared using auto or decltype(auto) Open ARM_18.1.0.LTS C++14 Section paragraph 8 states that if multiple declarators are on the same line as an auto or decltype(auto) specifying, they must all be variable declarations. However, our implementation does not enforce this requirement, allowing constructs of the following form: auto f(void)->int, g(void)->char;
CODEGEN-4244 armcl errors on legal constexpr constructor call Open ARM_18.1.0.LTS
CODEGEN-4234 No error generated for lambda-expression in default argument cannot capture any entity. Open ARM_18.1.0.LTS
CODEGEN-4228 armcl fails to flag an inconsistent use of alignas between a declaration and definition of an object Open ARM_18.1.0.LTS
CODEGEN-4203 Parser errors on empty enum declaration Open ARM_18.1.0.LTS The following code causes an error. enum : bool { }; While both gcc and clang mark this with a warning, our compiler marks it as an error, due to the declaration being functionally useless and most likely unintentional.
CODEGEN-4158 TI compiler does not emit clang error: constexpr function never produces a constant expression Open ARM_18.1.0.LTS
CODEGEN-4157 error with using constexpr for return from end() with empty std::initializer_list Open ARM_18.1.0.LTS
CODEGEN-4132 cannot find matching "==" operator definition Open ARM_18.1.0.LTS The library does not provide an definition of std::operator== for arguments of type std::istream_iterator. That is, the following code is erroneously marked as ill-formed with a diagnostic: #include <iterator> #include <string> using ISTREAM_ITER_C = std::istream_iterator<char, char>; bool foo(const ISTREAM_ITER_C& arg00 ,const ISTREAM_ITER_C& arg01 ){ return std::operator== (arg00, arg01); // Syntax error } However, this is only an issue if called in exactly that way. Using it as an operator, rather than as a function call, works as expected: arg00 == arg01 // Works
CODEGEN-4124 Failure to defer access control checks Open ARM_18.1.0.LTS
CODEGEN-4122 decltype cannot be used as a destructor name Open ARM_18.1.0.LTS
CODEGEN-4119 user-supplied allocator function is not called Open ARM_18.1.0.LTS
CODEGEN-4105 cannot find definition of ">=" operator Open ARM_18.1.0.LTS
CODEGEN-4099 Composing operations for valarray may fail to compile Open ARM_18.1.0.LTS Due to a potential implementation issue in the libc++ library, utilizing the valarray class and composing a result via multiple operations may fail. For example: const std::valarray<float> cl(6); std::slice arg1(0,0,0); std::slice slice(0,0,0); cl[arg1][slice]; // Compilation error!
CODEGEN-4091 Incomplete class type when using various members of <iterator> Open ARM_18.1.0.LTS The following code sample results in an incomplete type error: #include <iterator> int main(void) { bool always_false = false; if (always_false) { std::istreambuf_iterator<char> cl; std::istreambuf_iterator<char> var1; const std::istreambuf_iterator<char> & arg1 = var1; (void) cl.equal(arg1); } return 1; } The question is whether including <iterator> ought to include <streambuf>, which includes the definition for std::basic_streambuf, which is required by the definition of std::istreambuf_iterator.
CODEGEN-4090 Unimplemented core issue 475: std::uncaught_exception is not true when constructing the thrown object Open ARM_18.1.0.LTS In the code below, std::uncaught_exception should be true when constructing the A object that is constructed to be propagated to the catch block. The current implementation returns false. #include <exception> #include <assert.h> struct A { int i; A() : i(0) {} A(const A&) : i(std::uncaught_exception() ? 5 : 0) {} ~A() { } }; int main() { try { A a; assert(a.i == 0); throw a; } catch (A a) { assert(a.i == 5); // Fails } }
CODEGEN-4084 assembler errors with bogus .iendfunc asm directive when using --c_src_interlist Open ARM_18.1.0.LTS
CODEGEN-4076 Exception which propagates out of destructor does not result in std::terminate Open ARM_18.1.0.LTS
CODEGEN-4072 Unimplemented core issue 1769: Catching a thrown derived class by reference to base clas Open ARM_18.1.0.LTS Core 1769, involving a resolution which states that derived classes can be thrown and caught by catch clauses denoting an unambiguous base, has not been implemented. #include <assert.h> struct BaseClass { int i; BaseClass() : i(0) { } BaseClass(int ii) : i(ii) { } BaseClass(const BaseClass& r) : i(r.i) { } }; class DerivedClass : BaseClass { int ib; public: DerivedClass(const DerivedClass& r) : BaseClass(r.ib), ib(r.ib) { } DerivedClass(const BaseClass&) : BaseClass(999), ib(999) { } DerivedClass(int ii); }; DerivedClass thrown_base (1); DerivedClass::DerivedClass(int ii) : BaseClass(ii), ib(ii) { } int main() { try { throw thrown_base; return 999; } catch(const BaseClass &k) { } catch(...) { assert(false); } // Assertion fails at runtime due to core issue 1769 return 0; }
CODEGEN-4071 <regex> never throws error_ctype Open ARM_18.1.0.LTS Due to an implementation detail, the <regex> header will never throw an exception corresponding to std::regex_constants::error_ctype. This can be exhibited from the below code sample: #include <regex> int main(void) { try { std::regex e("[[:not_a_class:]]", std::regex_constants::ECMAScript); std::regex_match("a", e); } catch(std::regex_error e){ // e.code() will not be std::regex_constants::error_ctype } return 0; }
CODEGEN-4069 std::linear_congruential_engine doesn't support 8-bit results Open ARM_18.1.0.LTS Instantiations of std::linear_congruential_engine are only support for types between 64 and 16 bits. Therefore, on ARM and MSP430, the 'unsigned char' type is not supported.
CODEGEN-4058 std::function<T>::target_type() should return typeid(void) if target is empty Open ARM_18.1.0.LTS
CODEGEN-4050 shared_ptr::get_deleter() should return the original deleter class without copying Open ARM_18.1.0.LTS
CODEGEN-4044 libcxx istreambuf_iterator points to end of string instead of character past match Open ARM_18.1.0.LTS The C++11 standard says that the "iterator is always left pointing one position beyond the last character successfully matched." In this case, that's after zero characters, so the iterator should point to the first character, just as the test expects. However, libcxx doesn't do this; it returns the pointer to the end of the string, which is indeed composed of characters that might match a (hex) float, but that's not the final word. The libc++ code has advanced the iterator to "end," which it should not have done because the input sequence did not match. The test case expects the match to fail, leaving an iterator pointing to something other than "end," and it dereferences the iterator; because the iterator is actually "end", we get a NULL pointer dereference and hilarity ensues. I claim this is a flaw in the the libc++ implementation. cutdown test case: #include <locale> #include <sstream> typedef std::char_traits<char> test1; typedef std::istreambuf_iterator<char, test1> istr_it; struct mynum : public std::num_get<char, istr_it> { iter_type my_do_get(iter_type first, iter_type last, std::ios_base& str, std::ios_base::iostate& st, bool& val) const { return (do_get(first, last, str, st, val)); } }; int main() { mynum my_num_get; std::ios_base::iostate st = std::ios_base::goodbit; std::istringstream istr("abcdef"); istr_it first(istr.rdbuf()), last; st = std::ios_base::goodbit; double dv = 0; if(*(first = my_num_get.get(first, last, istr, st, dv)) == 'a') return 1; }
CODEGEN-4035 Compiler allows constant subtraction between pointers to different objects Open ARM_18.1.0.LTS The compiler allows the following code without error: struct STR { constexpr STR(): arr1{1,2}, arr2{3,4} {}; const char arr1[2]; const char arr2[2]; }; const struct STR str; constexpr char const *ptr1 = str.arr1; constexpr char const *ptr3 = str.arr2; constexpr int diff2 = ptr3 - ptr1; The definition of diff2 subtracts pointers to different objects, and should be disallowed.
CODEGEN-4032 wofstream << operator unexpected termination Open ARM_18.1.0.LTS
CODEGEN-4026 Non-standard partial ordering of variadic template partial specialization Open ARM_18.1.0.LTS
CODEGEN-4015 Access of const static member through pointer is not a constant expression. Open ARM_18.1.0.LTS The compiler emits an arguably spurious error on an access of a const static data member through a pointer when a constant expression is required. While gcc allows this silently, both the TI compiler and clang emit errors in stricter modes. struct C { const static int m; }; const int C::m = 4; C c, *cp = &c; int main(void) { struct S02 { int x : cp->m; // error, not a constant expression }; }
CODEGEN-4002 Undefined behavior on lambda capturing constexpr by reference Open ARM_18.1.0.LTS
CODEGEN-4001 Unimplemented core issue 588: Unqualified name lookup examines dependent base class Open ARM_18.1.0.LTS Similar to core issue 591 and CODEGEN-3963, this core issue resolves a lookup issue in a function template. In the following source code, the struct 'A' will examine the scope of the base class D<T> to resolve the unqualified reference to B, when the core issue resolution states that D<T> should be skipped and the B found in the function template 'g' should be used instead. struct B{ void f(int); }; template<class T> struct D: B { }; template<class T> void g() { struct B { void f(); }; struct A : D<T> { B m; }; A a; a.m.f(); // Presumably, we want ::g()::B::f(), not ::B::f(int) } int main () { g<int>(); return 0; }
CODEGEN-4000 Core 1601: Overload resolution for enum with fixed type Open ARM_18.1.0.LTS Core issue 1601 states that the following code should call the overload of 'b' which takes a char argument, but the compiler chooses the int overload. enum A : char { a }; int b(char) { return 1; } int b(int) { return 999; } int main() { printf("%d\n", b(a)); }
CODEGEN-3999 Unimplemented core issue 1374: Conversion sequence ranks qualification before reference binding Open ARM_18.1.0.LTS The following code will print B, when both gcc and clang print A. This is due to a resolution to core issue 1374, which reorders the rankings of conversion sequences such that qualification difference are accounted for after reference binding differences, rather than before. #include <stdio.h> typedef int * T1; typedef int *const T2; void foo(T1 &) { printf("A\n"); } // (1) void foo(T2 &&) { printf("B\n"); } // (2) int main() { foo((int *)0); // Normally prefers (2), but now prefers return 0; // (1) in GNU and Clang modes. }
CODEGEN-3998 Unimplemented core issue 1951: cv-qualified void and scalar types are not literal types Open ARM_18.1.0.LTS The type_trait helper std::remove_cv can ensure that qualifications have been stripped when using std::is_literal_type. The std::is_literal_type template function from the type_traits helper will erroneously have a value of 'false' for cv-qualified void and scalar types.
CODEGEN-3993 Constant initialiation may take place before dynamic initialization Open ARM_18.1.0.LTS In the following code, the rvalue reference 'br' will be initialized after the variable 'a', even though 'br' is constant initialized and 'a' is dynamically initialized. This ordering is required by C++14 Section 3.6.2 paragraph 2. extern int a; extern int f(); int a = f(); int&& br = 5; int f() { return br; } int main() { if (a != 5) return 1; return 0; }
CODEGEN-3991 We do not issue diagnostics if an allocation function throws a non bad_alloc exception Open ARM_18.1.0.LTS
CODEGEN-3966 slice_array assignment failures Open ARM_18.1.0.LTS
CODEGEN-3965 Invalid conversion on static_cast from T1 to rvalue reference of T2 Open ARM_18.1.0.LTS The following code results in a syntax error, while it is accepted by both gcc and clang. int main() { char c = 1; const int &&r = static_cast<const int&&>(c); return r; } As a workaround, 'c' may be cast to int. However, doing so will not bind reference r to the variable c.
CODEGEN-3964 Unimplemented core issue 1467: Overloads and initializations with single-element initializer_list Open ARM_18.1.0.LTS This core issue has gone many iterations of fixes, and boils down to the issue of: void foo(int x); // #1 void foo(std::initializer_list<char> x); // #2 foo({23}); // Calls #1 or #2? The compiler currently calls #1, while gcc/clang both call #2.
CODEGEN-3963 Unimplemented core issue 591: Name lookup in dependent base class that is also the current instantiation Open ARM_18.1.0.LTS The following code currently results in an error because the reference to B in the definition of A_<T>::C:: D is resolved to be C::B, which is void. Core issue 591 resolves this reference to A_<T>::B, which is int. template<class T> struct A_ { typedef int B; struct C { typedef void B; struct D; }; }; template<class T> struct A_<T>::C::D : A_<T> { B b; };
CODEGEN-3962 Core Issue 1804 unimplemented: friend declaration does not apply to class template specializations Open ARM_18.1.0.LTS The compiler does not yet implement the resolution to core issue 1804 involving template friend declarations applying to specializations of a class template. In the following code sample, a member of class C is inaccessible through a template friend declaration when the associated class template is a specialization. class C_; // Class template template<class T> struct A_ { int f(const C_&); struct D { int g() { return 8; } }; }; // Specialization template<> struct A_<int> { int f(const C_&); struct D { int g() { return 18; } }; }; class C_ { template<class T> friend int A_<T>::f(const C_&); // friend declaration int member; public: C_(int i) : member(i) { } }; template<class U> int A_<U>::f(const C_& c) { return c.member; } // Not specialized, C::member is accessible int A_<int>::f(const C_& c) { return 10+c.member; } // Specialized, C::member is inaccessible
CODEGEN-3961 Pack expansion in template parameter list fails Open ARM_18.1.0.LTS
CODEGEN-3959 std::reference_wrapper doesn't define argument_type for classes containing a typedef member named argument_type Open ARM_18.1.0.LTS C++14 section 20.9.3 paragraph 3 states that a reference_wrapper<T> shall define a typedef argument_type if T is a class type with a member type named argument_type. The implementation does not support this, and only defines the member types described in paragraphs 2, 3, and 4 if T inherits or is convertible to unary_function or binary_function.
CODEGEN-3954 Problem with std::swap and <tuple> Open ARM_18.1.0.LTS
CODEGEN-3953 scoped_allocator_adaptor can't be explicitly instantiated with two arguments Open ARM_18.1.0.LTS Due to an implementation detail in the library, a specialization of scoped_allocator_adaptor with two template arguments (example below) will cause a compilation error. #include <memory> #include <scoped_allocator> struct A00 : std::allocator<char> { A00() {} template <class P> A00(const P&) {} }; template <class T> struct A01 { typedef T value_type; A01() {} template <class P> A01(const P&) {} T* allocate(std::size_t n); void deallocate(T* p, std::size_t n); }; template <class T> std::allocator<T> a02(void) { return std::allocator<T>(); } int main() { std::scoped_allocator_adaptor<A00> a00; const std::scoped_allocator_adaptor<A00>& r00 = a00; if (!noexcept(std::scoped_allocator_adaptor<A01<int>, A00>( a02<int>(), r00))) return 1; }
CODEGEN-3951 Spurious error on bypassing initialization of trivially constructible objects Open ARM_18.1.0.LTS
CODEGEN-3948 Spurious syntax error on alignas in alias declaration Open ARM_18.1.0.LTS In the following code, the 'alignas' attribute on the declaration of s1a is marked as a syntax error, even though the C++ 14 grammar explicitly allows it. namespace a_ { struct alignas(0) s1 { int i; }; } int main() { using s1a alignas(0) = a_::s1; } Furthermore, alignas will currently be ignored in relaxed mode or marked as an error in strict mode if used to specify the alignment of an enumeration type or a lambda object.
CODEGEN-3947 Spurious error on unevaluated use of undefined constexpr function Open ARM_18.1.0.LTS
CODEGEN-3946 Spurious error on global qualifier of struct template Open ARM_18.1.0.LTS
CODEGEN-3944 Raw string d-char-sequence isn't supported Open ARM_18.1.0.LTS
CODEGEN-3941 operator<<(std::basic_ostream<K,T>&, const std::error_code&) is not defined in system_error Open ARM_18.1.0.LTS #include <ostream> to get the definition of the operator
CODEGEN-3938 std::rethrow_if_nested does not have standard signature Open ARM_18.1.0.LTS The standard states that std::rethrow_if_nested have the signature: template <class E> void rethrow_if_nested(const E& e); // C++14 18.8.6 p9 The library implementation adds a second paramter to its definition of the function for the purpose of utilizing SFINAE. This only affects uses of std::rethrow_if_nested if attempting to describe its signature as a type. As an example, the following attempt to capture the function pointer in a variable will fail to compile: void (*p)(const int&) = &std::rethrow_if_nested<int>;
CODEGEN-3937 nested_exception::rethrow_nested() not supported Open ARM_18.1.0.LTS
CODEGEN-3916 C++ header file cuchar is not provided in libc++ Open ARM_18.1.0.LTS The C++ header cuchar and its associated C header uchar.h are not available in our C++14 library due to lack of multibyte character string support.
SDSCM00052872 #pragma LOCATION and palign do not work together Open ARM_18.1.0.LTS One workaround is to use specific placement in the linker command file. In the C code, replace the #pragma LOCATION with a #pragma DATA_SECTION ... #pragma DATA_SECTION(device_fw_info_ptr, "for_device"); And in the linker command file, replace the whole .TI.bound line with this ... for_device > 0x00018000, palign(8), fill = 0xffffffff
SDSCM00052868 Automatic library build fails when an exact library name is used Open ARM_18.1.0.LTS Don't specify the name of the library.
SDSCM00052849 Compiler and assembler disagree on format for IT instruction Open ARM_18.1.0.LTS
SDSCM00052780 The armhex command does not handle spaces in the name of the output binary Open ARM_18.1.0.LTS
CODEGEN-1458 Consider splitting up unified_locale.cpp to save code space Open ARM_18.1.0.LTS
CODEGEN-1445 Compiler inserts unnecessary register copy Open ARM_18.1.0.LTS
SDSCM00051660 When the imaginary part of z is INFINITY, cprojf(z) is NOT equivalent to INFINITY + I * copysign(0.0, cimagf(z)) Accepted ARM_18.1.0.LTS
SDSCM00051484 Compiler does not respect partial overrides in C99 designated initializers Accepted ARM_18.1.0.LTS
SDSCM00051367 Disable diagnostic 1558 (--float_operations_allowed diagnostic) in standard header files Accepted ARM_18.1.0.LTS
SDSCM00051165 Should accept "LDRD R8,[R1]" in Thumb-2 mode Accepted ARM_18.1.0.LTS
SDSCM00051114 Missing half-precision float conversion functions Accepted ARM_18.1.0.LTS
SDSCM00051113 Missing __aeabi_read_tp Accepted ARM_18.1.0.LTS
SDSCM00051111 Missing AEABI_COMPATIBILITY_MODE link-time constants Accepted ARM_18.1.0.LTS
SDSCM00051086 Assembler accepts but mistranslates BLLT in v7 thumb mode Accepted ARM_18.1.0.LTS
SDSCM00051069 Should allow "ADD R0, R1, #0xfff" for v6m0 Accepted ARM_18.1.0.LTS Use the syntax "ADDW R0, R1, #0xfff" instead.
SDSCM00051065 Should accept 2-operand SUB SP in Thumb1/UAL mode Accepted ARM_18.1.0.LTS Use ADD SP, SP, #<imm> instead
SDSCM00050861 Should accept 2-operand add in ARM mode Accepted ARM_18.1.0.LTS
SDSCM00050499 The .label assembler directive should not be accepted when assembling for ELF. Accepted ARM_18.1.0.LTS
SDSCM00050131 Local struct with non-constant initializer treated as static scope variable Accepted ARM_18.1.0.LTS
SDSCM00049911 __aeabi_dcmpun returns 1 for Inf and -Inf Accepted ARM_18.1.0.LTS
SDSCM00049280 Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not Open ARM_18.1.0.LTS
SDSCM00049278 Array that is correctly initialized erroneously gets a MISRA diagnostic about size not being specified Open ARM_18.1.0.LTS
SDSCM00048267 Warning generated when using __curpc intrinsic on Thumb 2 Accepted ARM_18.1.0.LTS
SDSCM00047077 Incorrectly reduced double constant to float when ultimate destination is short Accepted ARM_18.1.0.LTS
SDSCM00046102 MISRA 12.8 and MISRA 10.5 false positives Accepted ARM_18.1.0.LTS
SDSCM00046074 Cortex-M0 library lacks uread4, etc. Open ARM_18.1.0.LTS If using the TI compiler, the TI compiler doesn't call any of these functions, so no workaround should be necessary. If using any other vendor's compiler and linking with the TI toolchain, link with the other vendor's toolchain.
SDSCM00040934 Structure is not initialized correctly when using -o2 or -o3 optimization Accepted ARM_18.1.0.LTS The initialization will have to be done at run-time, through a __sti initialization routine. You can see this routine when compiling without optimization. To workaround the compiler removing this initialization routine, initialize the object at the beginning of main: Info2.mSize = ((unsigned)_end_isr_stack - (unsigned)_start_isr_stack);
SDSCM00040523 The _ssat16 intrinsic allows literals in the range of 0-31, but the SSAT16 instruction only accepts values from 1-16 Accepted ARM_18.1.0.LTS
SDSCM00040522 _ssatl intrinsic allows 3rd argument to be 0 resulting in an assembler error. Accepted ARM_18.1.0.LTS
SDSCM00039636 When creating a partial linked ELF object file, the linker uses virtual addresses instead of relative addresses. Accepted ARM_18.1.0.LTS
SDSCM00039626 ARM assembler does not issue a warning for PC-relative loads when --embedded_constants=off Accepted ARM_18.1.0.LTS
SDSCM00037008 Linker outputting wrong build attribute name for EABI TAG_VFP_arch on ARM targets Accepted ARM_18.1.0.LTS
SDSCM00036874 Section relative ELF symbol values in partially linking object files should hold the section offset for the symbol Accepted ARM_18.1.0.LTS
SDSCM00018691 Linker gives misleading warning when dot expressions used in SECTION directive for .stack section Accepted ARM_18.1.0.LTS
SDSCM00014430 calloc doesn't check arguments to make sure the requested size is reasonable Accepted ARM_18.1.0.LTS
SDSCM00008685 DWARF does not correctly represent variables stored in register pairs Planned ARM_18.1.0.LTS Although 'var1' and 'var2' are shown to be in single registers, a debugger could determine that they are actually stored in register pairs by looking at the type of the variables: [00000113] DW_TAG_base_type DW_AT_name long long DW_AT_encoding 0x5 DW_AT_byte_size 0x8 The base type indicates that the size of the variables is 0x8 bytes. Since a single register can only store 0x4 bytes of information, it would take two registers to hold this values. On TI architectures, values stored in multiple registers are always stored in consecutive registers. Thus, the debugger would know that if the entire value could not fit in A4, the rest of the value must be in A5. A5 would contain the upper 32 bits of the value.
SDSCM00008543 Forward reference in .space generates an internal error Accepted ARM_18.1.0.LTS none
SDSCM00008248 Compilers on PC will not work without TMP set Accepted ARM_18.1.0.LTS Set the TMP environment variable, even if just set to . (current directory)

Generated on Mon Apr 30 17:23:08 2018