Intrinsics that operate on signed 8-bit types should be defined to accept "signed char" instead of "char", which are distinct types in C/C++. For intrinsics that accept references or pointers to signed 8-bit char in particular, this results in an incompatibility with host emulation, which defines these intrinics with int8_t (signed char). Previously, this was considered a known incompatibility between cl7x and host emulation. See SPRUIG6 "C7000 Host Emulation User's Guide", revision H, Section 4.2.1. https://www.ti.com/lit/ug/spruig6h/spruig6h.pdf

This is now considered a bug, but will only be fixed in 3.0.0 and later revisions of the compiler due to breaking API compatibility. In particular, the following intrinsics that had incompatible declarations between cl7x and host emulation will be consistently defined with signed char types in 3.0.0 and later compilers:

• __vload_dup(const signed char*)
• _vload_pred_dup(_vpred, const signed char*)
• __vload_unpack_short(const signed char*)
• _vload_pred_unpack_short(_vpred, const signed char*)
• __vload_unpack_int(const signed char*)
• _vload_pred_unpack_int(_vpred, const signed char*)
• __vload_unpack_long(const signed char*)
• _vload_pred_unpack_long(_vpred, const signed char*)
• __max_circ_pred(signed char, signed char&, __vpred&)
• __max_index(signed char, signed char&, __vpred&)
• __min_index(signed char, signed char&, __vpred&)

Other intrinsics that are not listed above, including vector versions of those intrinsics, will not result in incompatibility with previous compilers.