Description:
When intializing a static constexpr class member variable using a brace-enclosed expression, compilation fails with error "expected a ")"".
Affected Versions:
icpc (ICC) 19.1.0.166 20191121
Minimal example:
class Test
{
template< typename Foo >
static constexpr bool UseSMPAssign_v = (true) ;
};
int main(int argc, char** argv)
{
return 0;
}
Expected Result:
Minimal example compiles without errors
Actual Result:
Compilation Fails with
testmain2.cpp(4): error: expected a ")"
static constexpr bool UseSMPAssign_v = (true) ;
^
compilation aborted for testmain2.cpp (code 2)
Other Compilers:
GCC 8.3 and 9.2 are compiling the example
Note:
Omitting the Braces fixes the issue, but syntactically there should be nothing wrong adding them.
Hi,
We have also observed the error at our end. This seems to be a bug with the compiler.
Thanks for reporting. We will forward this issue to the respective engineering team.
Thanks
Prasanth
I have submitted this bug to our FrontEnd (CMPLRIL0-32644). In the meantime, can you remove the () as a workaround?
Thank you for submitting the bug. Unfortunately, trying to implement the workaround, I found another one, which looks related, but prevents me from using templated static constexpr member variables for SFINAE (and therefore the blaze-library) with icpc.
It seems like any bracketed expression in the assignment will fail compiling with the above error.
Minimal example:
class Test
{
template< typename Foo >
static constexpr bool UseSMPAssign_v = (true || false) && true ;
};
int main(int argc, char** argv)
{
return 0;
}
Expected Result:
Minimal example compiles without errors
Actual Result:
Compilation Fails with
testmain2.cpp(4): error: expected a ")"
static constexpr bool UseSMPAssign_v = (true || false) && true ;
^
compilation aborted for testmain2.cpp (code 2)
Other Compilers:
GCC 8.3 and 9.2 are compiling the example
Note:
() are needed here to logically structure the expression without relying on which order operators are executed according to the standard. Pretty sure, that there are cases constructible , which do not work without ().
I see. Hopefully, the fix will be in the next update compiler.
The fix apparently did not make it into the latest version (19.1.1.217)
Sorry for the inconvenient; 19.1.1.217 was built on Mar-6 (same day that this issue reported). Hence the fix couldn't be able to make it in.
Bug is still present in ICPC 19.1.2.254.
It will be fixed in the next major release compiler.
For more complete information about compiler optimizations, see our Optimization Notice.