| ID |
Summary |
State |
Reported In Release |
Target Release |
Workaround |
Release Notes |
| CODEGEN-5403 |
Improve documentation in Compiler Guides for PERSISTENT and NOINIT pragmas |
Accepted |
MSP430_18.1.3.LTS |
|
|
|
| CODEGEN-5187 |
Compiler mishandles conversions among integer types |
Accepted |
MSP430_18.1.3.LTS |
|
|
|
| CODEGEN-4329 |
Initializing unordered_map with an initializer_list fails with -o2 or higher |
Open |
MSP430_18.1.0.LTS |
|
|
The following code prints out 'wg size 1', instead of 'wg size 3', which is the expected value:
#include <unordered_map>
#include <initializer_list>
int main(void) {
const std::pair<const long, wchar_t>
wp0(0, L'i'), wp1(1, L'm'), wp2(2, L'p');
std::initializer_list<std::unordered_map<long, wchar_t>::value_type>
winit { wp0, wp1, wp2 };
std::unordered_map<long, wchar_t> wg(winit);
printf("wg size %zu\n", wg.size());
} |
| CODEGEN-4323 |
MSP430 floating point calculation is inconsistent |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4318 |
libcxx/include/random uses unsigned for unsigned long |
Open |
MSP430_18.1.0.LTS |
|
|
LIBCXX/libcxx/include/random shown below uses unsigned instead of unsigned long for the "32" bit case of __lce_ta:
// 32
template <unsigned long long _Ap, unsigned long long _Cp, unsigned long long _Mp>
struct __lce_ta<_Ap, _Cp, _Mp, (unsigned long)(~0), true>
{
typedef unsigned long result_type;
...
armcl/clang both compile with no errors.
msp430, however, has 16bit "unsigned" and fails with below error due to above issue where "unsigned" is used for 32 bit. It should use unsigned long instead:
"random", line 1890: error: incomplete type is not allowed
detected during:
instantiation of "std::__2::linear_congruential_engine<_UIntType, __a, __c, __m>::result_type std::__2::linear_congruential_engine<_UIntType, __a, __c, __m>::operator()() [with _UIntType=uint_fast32_t, __a=40014UL, __c=0UL, __m=2147483563UL]" at line 2651
instantiation of "void std::__2::subtract_with_carry_engine<_UIntType, __w, __s, __r>::seed(std::__2::subtract_with_carry_engine<_UIntType, __w, __s, __r>::result_type, std::__2::integral_constant<unsigned int, 1U>) [with _UIntType=uint_fast32_t, __w=24UL, __s=10UL, __r=24UL]" at line 2576
Tests compile and pass if above __lce_ta is changed for 32bit case from unsigned to unsigned long.
|
| CODEGEN-4305 |
Compiler aborts with excessive inlining of C++ functions |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4304 |
runtime failure on unaligned access (on some processor variants, not all) |
Open |
MSP430_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-4297 |
Cannot take the address of std::ctype<char>::table_size |
Open |
MSP430_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-4281 |
Unexpected type returned by bitset [] operator |
Open |
MSP430_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 |
MSP430_18.1.0.LTS |
|
|
The library does not declare std::multimap::clear as noexcept, which is required by C++14 section 23.4.5.1 paragraph 2 |
| CODEGEN-4275 |
std::num_get does not parse floating-point strings correctly |
Open |
MSP430_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 |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4258 |
deeply nested lambda functions hang the codegen |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4248 |
armcl allows non-default arguments to be specified after default arguments |
Open |
MSP430_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 |
MSP430_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-4245 |
Multiple non-variables may be declared using auto or decltype(auto) |
Open |
MSP430_18.1.0.LTS |
|
|
C++14 Section 7.1.6.4 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-4234 |
No error generated for lambda-expression in default argument cannot capture any entity. |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4158 |
TI compiler does not emit clang error: constexpr function never produces a constant expression |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4157 |
error with using constexpr for return from end() with empty std::initializer_list |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4132 |
cannot find matching "==" operator definition |
Open |
MSP430_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 |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4122 |
decltype cannot be used as a destructor name |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4119 |
user-supplied allocator function is not called |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4099 |
Composing operations for valarray may fail to compile |
Open |
MSP430_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-4090 |
Unimplemented core issue 475: std::uncaught_exception is not true when constructing the thrown object |
Open |
MSP430_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-4087 |
wostringstream::fill(WCHAR_MAX) incorrectly sets the fill value to ' 'L. |
Accepted |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4076 |
Exception propagating out of noexcept function does not call std::terminate |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4072 |
Unimplemented core issue 1769: Catching a thrown derived class by reference to base clas |
Open |
MSP430_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 |
MSP430_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 |
MSP430_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-4044 |
libcxx istreambuf_iterator points to end of string instead of character past match |
Open |
MSP430_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 |
MSP430_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-4026 |
Non-standard partial ordering of variadic template partial specialization |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4002 |
Undefined behavior on lambda capturing constexpr by reference |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-4001 |
Unimplemented core issue 588: Unqualified name lookup examines dependent base class |
Open |
MSP430_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 |
MSP430_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 |
MSP430_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 |
MSP430_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 |
MSP430_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-3966 |
slice_array assignment failures |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-3965 |
Invalid conversion on static_cast from T1 to rvalue reference of T2 |
Open |
MSP430_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 |
MSP430_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 |
MSP430_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 |
MSP430_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 |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-3951 |
Spurious error on bypassing initialization of trivially constructible objects |
Open |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-3948 |
Spurious syntax error on alignas in alias declaration |
Open |
MSP430_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 |
MSP430_18.1.0.LTS |
|
|
|
| CODEGEN-3946 |
Spurious error on global qualifier of struct template |
Open |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00052531 |
Incorrect value assigned to a forward reference of a symbol defined in terms of the section's PC ($) after jump expansion |
Open |
MSP430_18.1.0.LTS |
|
Two workarounds are possible:
1) Use a label to get the value of the PC at a key location instead of "symbol .equ $"
2) Replace the jump that will be expanded with an already expanded form. In the example, the jump could be replaced with:
JLO $+6
BR label1 |
|
| CODEGEN-1295 |
MSP430 RTS rint() double routines failing for some inputs |
Open |
MSP430_18.1.0.LTS |
|
Avoid using the rint() RTS routines with double arguments and instead use the corresponding rint() float routines.
|
MSP430 RTS routines rint() rintl() lrint() lrintl() llrint() llrintl() failing for some inputs with double arguments.
|
| SDSCM00051908 |
Print a more friendly message when using a lnk.cmd with too large memory |
Accepted |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00050131 |
Local struct with non-constant initializer treated as static scope variable |
Accepted |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00049280 |
Ill advised enum scalar usage gets MISRA diagnostic, but similar usage of enum array does not |
Open |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00049278 |
Array that is correctly initialized erroneously gets a MISRA diagnostic about size not being specified |
Open |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00047833 |
msp C++ cpp compiled with printf_support=minimal causes cout to output incorrect results |
Accepted |
MSP430_18.1.0.LTS |
|
Instead either compile without --printf_support, or choose options nofloat or full. |
|
| SDSCM00046695 |
Floating point addition rounding error |
Accepted |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00046115 |
MSP430 RTS float arithmetic functions do not round correctly |
Open |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00046113 |
C2000 RTS float arithmetic functions do not round correctly |
Open |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00044526 |
Compiler emits bogus DW_OP_reg16 for split argument |
Accepted |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00040934 |
Structure is not initialized correctly when using -o2 or -o3 optimization |
Accepted |
MSP430_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);
|
|
| SDSCM00038293 |
Relocation overflows for BIT instruction using 20-bit pointer |
Accepted |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00038178 |
Should forbid non-const objects larger than 64k in large model if --near_data=globals |
Accepted |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00018691 |
Linker gives misleading warning when dot expressions used in SECTION directive for .stack section |
Accepted |
MSP430_18.1.0.LTS |
|
|
|
| SDSCM00008685 |
DWARF does not correctly represent variables stored in register pairs |
Planned |
MSP430_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.
|
|
| SDSCM00008652 |
pow(2,x) has fairly significant rounding error |
Accepted |
MSP430_18.1.0.LTS |
|
Please describe the workaround for this problem.
|
|
| SDSCM00008630 |
printf gives wrong value for pointer when its value is incremented |
Open |
MSP430_18.1.0.LTS |
|
To get rid of the warning message modify the printf statement as
follows:
printf('0x%lx\n', 0x10000 + (t=(long int)&global_var));
This modified code executes correctly too.
|
|
| SDSCM00008543 |
Forward reference in .space generates an internal error |
Accepted |
MSP430_18.1.0.LTS |
|
none
|
|
| SDSCM00008248 |
Compilers on PC will not work without TMP set |
Accepted |
MSP430_18.1.0.LTS |
|
Set the TMP environment variable, even if just set to . (current directory)
|
|
