Workaround for __int128 error?

Unfortunately CLion doesn't seem to recognize __int128 under gcc (which is strange, since it recognizes other gcc built-ins, like __builtin_popcount(...)).  I know there is an "issue" about it, pending, which hasn't seem to be addressed since originally posted two years ago in Oct 2014: https://youtrack.jetbrains.net/issue/CPP-1418

My question: is there a work-around to get CLion to ignore the false syntax error without having to disable inspection altogether?  It's becoming a real pain, since that one false error then bleeds in to the rest of the code causing CLion to think I have thousands of errors.  My code compiles and runs fine.

Things I've tried: ``using`` and ``typdef`` in an attempt to limit the error to one line.  Unfortunately this doesn't really work, since anything used later that uses the typedef causes strange, seemingly unrelated errors.  For example, the following generates a "subscripted value is not an array" error on a vector:

#include <vector>

using int128_t = __int128;
using intpair = std::pair<int128_t,int128_t>;

int main() {

std::vector<intpair> pairs;
pairs.push_back({10, 20});
pairs.push_back({20, 30});
int b = (int)(pairs[0].first); // Subscripted value is not an array?!?!

return 0;
}

I've also tried using an ifdef guard to try to trick CLion into thinking it is defined while getting the compiler to ignore the statement, but CLion seems to be too smart. It is able to correctly detect any defined symbols, and reports the same error.

#ifdef __GARBAGE__
using int128_t = __int128;
#endif

 

Does anyone have any other ideas? Or know of a way for me to tell CLion that the symbol does actually exist?

4 comments
Comment actions Permalink

It looks like they are working on support for __int128 here: https://youtrack.jetbrains.com/issue/CPP-1418#tab=Changes

In the meanwhile, I used this solution to avoid the error messages:

#pragma clang diagnostic push
#pragma ide diagnostic ignored "CannotResolve"
typedef __int128 bigint;
#pragma clang diagnostic pop

0
Comment actions Permalink

Adding the line

#pragma ide diagnostic ignored "CannotResolve"

only avoids the original Cannot Resolve error message.  For the snippet provided in the post, I still get the "Subscripted value is not an array" error.  I end up getting thousands of others like it littered throughout my code, making the inspections completely useless.  These all go away if I use another integer type like ``long long`` instead.

The only "workaround" I have found to be useable is to redefine the symbol ``__int128``, surrounding by an ifdef guard, then compile via command-line with a SEPARATE makefile that disables that code  (since the compiler will complain about redefining the symbol).  It means I cannot build through CLion directly.

0
Comment actions Permalink

What about

typedef unsigned long long int uint128_t __attribute__ ((mode (TI)));

Compiler knows attribute. IDE doesn't. Thus there can be conflicts.

0
Comment actions Permalink

Yes, thanks @Albrezgin!  That does it!

0

Please sign in to leave a comment.