This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software: TI C/C++ Compiler
Hello,
We found minor issue, which manifested with newer CGT (older CGT isn't affected). We're not sure, if this is bug or improvement in new compiler. Here is sample code, which triggers error:
typedef unsigned int u32;
template <bool TYPE> struct TestStruct {};
template <> struct TestStruct<false>
{
static const u32 value = 0;
};
template <> struct TestStruct<true>
{
u32 value;
void init(u32 val) { value = val; }
};
int main()
{
u32 i=0;
TestStruct<false> TF;
TestStruct<true> TT;
if(i < TF.value)
{
;
}
TT.init(0);
if(i < TT.value)
{
;
}
TT.init(3);
if(i < TT.value)
{
;
}
return 0;
}
signedUnsignedTemplate_issue_for_TI.zip
In our case, we have "for" loop with template member to be checked in condition and this could be problematic, because it disturbs templatization. What is also worth to mention is fact, that putting "volatile" additionally to line 7 "solves" issue, so it means, that probably aggresive optimisation takes place here. On the other hand, affected code based on bad design rather and we need to refactor it somehow. Nevertheless, we would like to know, if new compiler isn't too overprotective in this respect.
If this is a bug, then please include fix together with RSA intrinsics in new release.
Best Regards,
ZD
One clarification - the name of sample "signedUnsignedTemplate" describes the fact, that changing loop variable type from u32 to int "solves" issue too, but this is not the root cause here...
I presume you are concerned about the fact that when built with version 8.3.4, this happens ...
"main.cpp", line 23: error #188-D: pointless comparison of unsigned integer with zero 1 error detected in the compilation of "main.cpp". >> Compilation failure
Here is line 23 ...
if(i < TF.value)
The variable i is unsigned, and the expression TF.value resolves to the value 0. The compiler can see this comparison is always false, and so it issues that diagnostic.
Normally, this diagnostic is a warning, and the build succeeds. However, because you use the option --emit_warnings_as_errors, this diagnostic is an error, and the build fails.
Version 7.4.24 does not issue a diagnostic in this case. Because the compiler is not required to issue this diagnostic, that is not a bug. That version 8.3.4 issues the diagnostic is a small improvement.
Thanks and regards,
-George
George Mock said:Version 7.4.24 does not issue a diagnostic in this case.
Thank you. This clarifies our concerns. I also checked some older online compilers like Clang and this statement is true there too. We can close this topic.
Best Regards,
ZD