C7000 C/C++ Code Generation Tools v1.4.2.LTS Release Notes
Table of Contents
- 0 Introduction to the C7000 Code Generation Tools v1.4 LTS
- 1 Documentation
- 2 TI E2E Community - Where to get help
- 3 Defect Tracking Database
- 4 SE/SA/MMA Interface Changes
- 5 Complex Types Unsupported for Some Intrinsics
- 6 Data Movement Intrinsic Updates
- 7 API Updates for Constant Arguments
- 8 Supported and Unsupported Features
- 9 Support for Vector Data Types
- 10 Removal of MISRA 2004 compiler command-line options
- 11 Silicon errata i2117 workaround support
- 12 Half-float conversion intrinsics
- 13 Resolved defects
- 14 Known defects
0 Introduction to the C7000 Code Generation Tools v1.4 LTS
This release is an LTS (Long-Term Support) release.
Definitions
Active releases have bug fixes applied pro-actively and patch releases occur on a semi-regular schedule (2-3 months)
Reactive releases only have a subset of bug fixes applied and patch releases occur only when requested or are deemed necessary.
Patch releases only contain bug fixes (no new features)
Short term support (STS) release: All STS branches will be made reactive upon creation. A patch release for this branch will only be created for production stop issues and will only contain fixes for the production stop issues. For all other issues, users are advised to wait for the next STS branch, which may also contain new features. An STS release will occur approximately every 3 months after the first LTS release.
Long term support (LTS) release: The LTS branch will be active upon creation. The branch will be active for at least 2 years. Production stop bugs will be fixed within 15 days of being reported. Planned patch releases expected every 2-3 months to correct any critical bugs within 60 days of being reported. The LTS release is intended for customers to lock down on tools. We will have no more than one LTS per year.
We normally maintain two active branches at any given time. When a new LTS branch is made, the 2nd to last LTS releases will be made reactive.
1 Documentation
The following documents are included to provide information on how to use, program, and migrate to the C7000 CPU.
SPRUIG8B***.PDF: C7000 C/C++Optimizing Compiler Users Guide
SPRUIV4***.PDF: C7000 Optimization Guide
SPRUIG4C***.PDF: C7000 Embedded Application Binary Interface (EABI) Reference Guide
SPRUIG5C***.PDF: C6000-to-C7000 Migration User’s Guide
SPRUIG3C***.PDF: VCOP Kernel-C to C7000 Migration Tool User’s Guide
SPRUIG6D***.PDF: C7000 Host Emulation User’s Guide (NOTE: Host Emulation is an experimental feature)
2 TI E2E Community - Where to get help
Questions concerning TI Code Generation Tools can be posted to the TI E2E Community forums. The “Development Tools” forum can be found at:
The following is the top-level webpage for all of TI’s Code Generation Tools.
If submitting a defect report, please attach a scaled-down test case with command-line options and the compiler version number to allow us to reproduce the issue easily.
3 Defect Tracking Database
Compiler defect reports can be tracked at the new Development Tools bug database, SIR. SIR is a JIRA-based view into all public tools defects. The old SDOWP tracking database will be retired.
A my.ti.com account is required to access this page. To find an issue in SIR, enter your defect id in the top right search box once logged in. Alternatively from the top red navigation bar, select “Issues” then “Search for Issues”.
To find an old SDOWP issue, place the SDOWP ID in the search box and use double quotes around the SDOWP ID.
4 SE/SA/MMA Interface Changes
As of version 1.3.0, the compiler has a different interface for the streaming engine (SE), streaming address generator (SA) and to a lesser extent, the MMA. These changes involve how to setup and initialize the SE and SA and the enums used in initializing configuration registers and some intrinsics.
Existing code that uses the SE, SA, or MMA will need to be changed to use the new interfaces with this version of the compiler. See the “c7x_strm.h” and “c7x_mma.h” files in the include directory for the current interface.
Here is a summary of some of the interface changes
- The
__HWAOP()
and__HWAOPXFER()
intrinsics require an enum argument instead of a simple integer constant. - The
__HWA_CONFIG_REG
name has changed to__HWA_CONFIG_REG_v1
to allow for additional MMA configuration templates in future devices. - Some fields in the
__HWA_CONFIG_REG_v1
struct now require enums instead of constants. - It is recommended to use the
__gen_HWA_CONFIG_REG_v1()
function to set default values for any new instance of the__HWA_CONFIG_REG_v1
struct. There is a similar function,__gen_HWA_OFFSET_REG()
for initializing instances of the__HWA_OFFSET_REG
struct. - SE and SA are now configured using structure types. It is recommended to use
__gen_SE_TEMPLATE_v1()
and similar to initialize them.
As a temporary migration measure, the option --deprecated_api
is available to expose the old API and hide the new API. This option will be removed in a future release.
In addition, as of version 1.4.0, the streaming address generator (SA) API has been modified to give greater compatibility with typedefs and const pointers. For example, __SA0ADV(int2_typedef, ptr)
was disallowed, but is now legal. Similarly, __SA0ADV(const_int2, ptr)
is also now legal and will return a const pointer. For more information, consult the descriptions in “c7x_strm.h”.
5 Complex Types Unsupported for Some Intrinsics
As of version 1.3.0, due to the potential for incorrect address scaling when the streaming address generator (SA) is used, the following intrinsics no longer support complex types and complex vector types.
__vload_unpack_short()
__vload_unpack_int()
__vload_unpack_long()
__vstore_packl()
__vstore_packh()
__vstore_packhs1()
__vstore_pack_byte()
__vstore_packl_2src()
__vstore_packh_2src()
__vstore_packhs1_2src()
__vstore_pack_byte_2src()
6 Data Movement Intrinsic Updates
Version 1.3.0 implemented new data movement intrinsics that broke compatibility with previous versions. A data movement intrinsic is defined as an intrisic that moves data without regard for data format, such as a shuffle or deal operation. These intrinsics have been updated to only accept element types that precisely fit the data movement operation. For example, a shuffle operation that operates on 32 bit boundaries no longer accepts char vectors. In addition, any element type that may fit is now available, including complex and floating point types. For reference, the following intrinsics were affected:
__deal_stride2()
__deal_stride4()
__duplicate()
__pack_consec_high_char()
__pack_consec_high_int()
__pack_consec_high_long()
__pack_consec_high_short()
__pack_consec_low_char()
__pack_consec_low_int()
__pack_consec_low_long()
__pack_consec_low_short()
__pack_even_cross_short()
__pack_even_short()
__pack_high_char()
__pack_high_low_short()
__pack_high_short()
__pack_low_char()
__pack_low_high_char()
__pack_low_high_short()
__pack_low_int()
__pack_low_short()
__reverse()
__shuffle_stride2()
__shuffle_stride2_even_even()
__shuffle_stride2_even_odd()
__shuffle_stride2_high_high()
__shuffle_stride2_low_high()
__shuffle_stride2_low_low()
__shuffle_stride2_odd_odd()
__shuffle_stride4()
__swap()
This set of intrinsics has been replaced with the following set:
__deal_stride2()
__deal_stride4()
__duplicate()
__duplicate16()
__duplicate2()
__duplicate32()
__duplicate4()
__duplciate8()
__pack()
__pack_consec_high()
__pack_consec_low()
__pack_even()
__pack_even_cross()
__pack_high()
__pack_high_low()
__pack_low()
__pack_low_high()
__reverse()
__shuffle_stride2()
__shuffle_stride2_even_even()
__shuffle_stride2_even_odd()
__shuffle_stride2_high_high()
__shuffle_stride2_low_high()
__shuffle_stride2_low_low()
__shuffle_stride2_odd_odd()
__shuffle_stride4()
__swap()
In version 1.3.0, these changes were not present in host emulation. Version 1.4.0 corrects this difference.
7 API Updates for Constant Arguments
Version 1.4.0 adjusted some intrinsics to ensure that they only accept constant arguments and/or enumeration arguments. The following intrinsics are affected:
__get_indexed()
__set_indexed()
__mtag()
__memory_fence()
__memory_fence_store()
__se_cache_op()
__se_cache_preload()
8 Supported and Unsupported Features
New Features
- Host Emulation is an experimental feature
- Host Emulation is an experimental feature and may not work as intended or expected in certain situations. In addition, there may be limitations that exist that are not disclosed in the Host Emulation User’s Guide, SPRUIG6E.
- Host Emulation Additions
- Support for
__SEn_OPEN_SHORTCUT()
intrinsics. - Support for
__TI_COMPILER_VERSION__
macro. - Support for const vector types. For example, instead of
const int4 *
,const_int4_ptr
should be used for host emulation compatibility.
- Support for
- Basic support for boolean vector types
- Language support is incomplete. For example, conversions to other vector types and subvector accesses are not supported.
- For performance critical code or code that needs more precise control of predicates, continued use of the
__vpred
type may be preferable. __vpred
intrinsics are documented in “c7x_vpred.h”.
- Added constant folding of vector types (as of version 1.3.0)
- This support also provides minimal support for constexpr vectors when folding occurs.
- Reworked directory and file structure for host emulation (as of version 1.3.0)
The following header renames have occurred to more closely resemble the toolchain’s header names:
c6x_he_migration.h -> c6x_migration.h c7x_host_emulation.h -> c7x.h c7x_he_ecr.h -> c7x_ecr.h c7x_he_luthist.h -> c7x_luthist.h c7x_he_mma.h -> c7x_mma.h c7x_he_strm.h -> c7x_strm.h c7x_he_strm_struct.h -> c7x_strm_struct.h
Include directories are based on the C7x subtarget. Use the following instead of “include”:
include/C7100
- Inclusion of “c7x.h” now sets a subtarget macro,
__C7100__
. - Implementation details for host emulation are now hidden in the ti_he_impl subdirectory to avoid naming conflicts with user applications.
Only “c6x_migration.h” and “c7x.h” may be included by user applications. This matches the behavior for the toolchain headers.
Supported Intrinsics
The included top-level header files “c7x.h” and “c6x_migration.h” list the supported intrinsics for both C7x and C6x, respectively. Note that you must include these header files with your source in order to leverage many of the C7x intrinsics and all of the legacy C6x intrinsics. “c7x.h” includes other useful header files that document/describe supported intrinsics:
- c7x_vpred.h: List of intrinsics supporting low-level
__vpred
vector predicate type. - c7x_direct.h: List of intrinsics that map directly to instructions.
- c7x_strm.h: List of intrinsics and flags for C7x Streaming Engine and Stream Address Generator.
- c7x_mma.h: List of intrinsics and associated structures and enumerations for the C7x MMA.
- c7x_luthist.h: List of intrinsics and flags for C7x Lookup Table / Histogram support.
Unsupported Features
- Automatic leveraging of Streaming Engine and Stream Address Generator
- OpenCL-C & LLVM
9 Support for Vector Data Types
The C7000 C/C++ compiler supports the use of OpenCL-like vector data types in C/C++ source files by default.
9.1 Basic Usage
Support for vector data types is available on the C7100 architecure.
Support for vector data types is enabled by default. When the --vectypes=off
option is specified on the compiler command line, vector types will be interpreted as identifiers rather than types.
All of the vector data types and related built-in functions that are supported in the C7x programming model are specified in the “c7x.h” header file that you can find in the “include” sub-directory where your C7000 CGT was installed.
Any C/C++ source file that utilizes vector data types or any of the built-in functions must #include <c7x.h>
in that source file.
9.2 Vector Data Types and Operations
Vector Data Types
A vector type name is a concatenation of element type name with a number representing vector length. A vector with such type consists of vector length number of vector elements.
The C7x programming model implementation of vector data types and operations follows the OpenCL C language specification very closely. For a more detailed description of OpenCL vector data types and operations, please see “The OpenCL Specification” version 1.2 which is available from the Khronos OpenCL Working Group:
http://www.khronos.org/opencl/
Chapter 6, section 6.1.2 of “The OpenCL Specification” version 1.2 provides a detailed description of the built-in vector data types supported in the OpenCL C programming language.
The C7x programming model provides the following built-in vector data types:
Element type names and sizes
char char, 8 bits uchar unsigned char, 8 bits short short, 16 bits ushort unsigned short, 16 bits int int, 32 bits uint unsigned int, 32 bits long long, 64 bits ulong unsigned long, 64 bits float IEEE single precision floating-point, 32 bits double IEEE double precision floating-point, 64 bits
Minimum valid vector lengths: 2, 3, 4, 8, 16
For example, a
uchar8
is a vector of 8 unsigned chars. Its length is 8 and its size is 64 bits.The following vector types are also available as an extension to the OpenCL C programming language:
char32 char64 uchar32 uchar64 short32 ushort64
The C7x programming model also provides an extension to the OpenCL C programming language for representing vectors of complex type. A prefix of c
is used to indicate a complex type name. Each complex type vector element contains a real part and an imaginary part with the real part occupying the lower address in memory.
Complex element type names and sizes:
cchar complex char type, 16 bits cshort complex short type, 32 bits cint complex int type, 64 bits clong complex long type, 128 bits cfloat complex float type, 64 bits cdouble complex double type, 128 bits
Valid lengths for complex type vectors: 1, 2, 4, 8
For example, a
cfloat2
is a vector of 2 complex floats. Its length is 2 and its size is 128 bits. Eachcfloat2
vector element contains a real float and an imaginary float.The following complex vector types are also available:
cchar16 cchar32 cshort16
Vector Operations: component access
A component access can occur on the left-hand-side (lhs) or right-hand-side (rhs) of an assignment operator. If specified on the lhs of an assignment, each component must be uniquely identifiable.
The C7x programming model implementation supports OpenCL C like swizzle operators:
A suffix of
.x
,.y
,.z
, or.w
can be used to access an element of a vector whose length is <= 4.char4 my_c4 = (char4)(1, 2, 3, 4); char tmp = my_c4.y * my_c4.w; /* ".y" accesses 2nd element * ".w" accesses 4th element * tmp = 2 * 4 = 8; */
A suffix of
.s0
,.s1
, …,.s9
,.sa
, …,.sf
can be used to access one of up to 16 elements in a vector.uchar16 ucvec16 = (uchar16)(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 ); uchar8 ucvec8 = (uchar8)(2, 4, 6, 8, 10, 12, 14, 16); int tmp = ucvec16.sa * ucvec8.s7; /* ".sa" is 11th element of ucvec16 * ".s7" is 8th element of ucvec8 * tmp = 10 * 16 = 160; */
A suffix of
.even
or.odd
can be used to access the even or odd elements of a vector.ushort4 usvec4 = (ushort4)(1, 2, 3, 4); ushort2 usvecodd = usvec4.odd; /* usvecodd = (ushort2)(2, 4); */ ushort2 usveceven = usvec4.even; /* usveceven = (ushort2)(1, 3); */
A suffix of
.hi
or.lo
can be used to access the elements in the upper half of a vector (for.hi
) or the elements in the lower half of a vector (for.lo
).ushort8 usvec8 = (ushort8)(1, 2, 3, 4, 5, 6, 7, 8); ushort4 usvechi = usvec8.hi; /* usvechi = (ushort4)(5, 6, 7, 8); */ ushort4 usveclo = usvec8.lo; /* usveclo = (ushort4)(1, 2, 3, 4); */
The C7x programming model also supports an extension to the OpenCL C programming language for accessing elements of a complex type vector:
A suffix of
.r
can be used to access the real parts of each of the elements in a complex type vector.cfloat2 cfa = (cfloat2)(1.0, -2.0, 3.0, -4.0); float2 rfa = cfa.r; /* ".r" accesses real parts of cfa elements * rfa = (float2)(1.0, 3.0); */
A suffix of
.i
can be used to access the imaginary parts of each of the elements in a complex type vector.cfloat2 cfa = (cfloat2)(1.0, -2.0, 3.0, -4.0); float2 ifa = cfa.i; /* ".i" accesses imaginary parts of cfa elements * ifa = (float2)(-2.0, -4.0); */
Swizzle operators can also be combined if the result of the combination is well-defined:
ushort4 usvec4 = (ushort4)(1, 2, 3, 4); ... usvec4.hi.even = 5; /* After this assignment, * usvec4 contains (1, 2, 5, 4) */
Vector Operations: concatenation
Scalar entities or shorter vectors can be concatenated together to form longer vectors. When all of the components involved are constants, the result is a vector literal. Otherwise, the vector’s value is determined at run-time.
Vector literals
(short4)(1, 2, 3, 4); (float2)(3.2, -2.3);
Vector concatenation
void foo(int a, int b) { int2 myvec = (int2)(a, b); ... }
Vector Operations: conversion and re-interpretation
The C7x programming model includes functions that can convert or re-interpret the elements of one vector type as another vector type.
convert_<destination type>(<source type object>)
can be used to perform an element by element conversion of one vector type object into another vector type object. The source vector type and the destination vector type must be the same length.void foo(int a, int b) { /* initialize a short2 vector from a converted int2 vector */ short2 svec2 = convert_short2((int2)(a, b)); ... }
as_<destination type>(<source type object>)
can be used to re-interpret the original vector type of an object as another vector type. The source type and destination type must be the same size.extern longlong lla; float2 fltvec2 = as_float2(lla);
The convert_<destination type>(<source type object>)
operation may be used with complex types, but only when converting from one complex type to another. (Such as from cint2
to cfloat2
.)
Vector Operations: infix operators
When infix operators are applied to vector type objects, the operator is applied element by element. That is, each element in the result vector is the result of applying the infix operator to the corresponding elements in the source vector(s).
Unary:
Negate: - Bitwise complement: ~ Logical not (integer vectors only): ! int4 pos_i4 = (int4)(1, 2, 3, 4); int4 neg_i4 = -pos_i4; /* Use of negate operator initializes * neg_i4 to (-1, -2, -3, -4) */
Binary
Assignment operators:
=
, op= (+=
, for example)Arithmetic operators:
+
,-
,*
,/
Modulo operator (integer vectors only):
%
Bitwise operators:
&
,|
,^
,<<
,>>
Relational operators:
>
,>=
,==
,!=
,<=
,<
Increment / decrement (integer vectors only):
++()
,()++
,--()
,()--
Logical operators (integer vectors only):
&&
,||
/* Assume iv4 argument contains (1, 2, 3, 4) coming in */ void foo(int4 iv4) { int4 local_iva = iv4++; /* local_iva = (1, 2, 3, 4) */ int4 local_ivb = iv4++; /* local_ivb = (2, 3, 4, 5) */ /* local_ivc = (1, 2, 3, 4) + (2, 3, 4, 5) = (3, 5, 7, 9) */ int4 local_ivc = local_iva + local_ivb; } /* iv4 contains (3, 4, 5, 6) on exit from foo() */
Operators available with complex vector types
Arithmetic operators:
+
,-
,*
,/
Increment / decrement (by 1+0i):
++()
,()++
,--()
,()--
/* On C7100, the compiler will generate a special instruction to */ /* carry out the complex multiply operation and call a built-in (RTS) */ /* function to carry out the divide operation. */ void foo() { cfloat2 va = (cfloat2) (1.0, -2.0, 3.0, -4.0); cfloat2 va = (cfloat2) (4.0, -2.0, -4.0, 2.0); /* For details about the rules for complex multiplication and */ /* division, please see Annex G of the C99 C language */ /* specification. */ /* vc = < (0.0, -10.0), (-4.0, 22.0)> */ cfloat2 vc = va * vb; /* vd = < (0.4, -0.3), (-1.0, 0.5)> */ cfloat2 vd = va / vb; ... }
Vector Operations: built-in functions
Prototypes for all of the vector built-in functions supported in the C7x programming model are listed in the “c7x.h” header file that you can find in the “include” sub-directory where your C7000 CGT package was installed. Please refer to the contents of “c7x.h” for a complete list of the vector built-in functions.
Here is an example which uses vector built-in functions:
[vbif_ex.c]
#include <stdio.h>
#include <c7x.h>
void print_short4(char *s, short4 v)
{
printf("%s", s);
printf(" <%d, %d, %d, %d>\n", v.x, v.y, v.z, v.w);
}
int main()
{
short4 va = (short4) (1, 2, 3, -32766);
short4 vb = (short4) (5, 32767, -13, 17);
short4 vc = va + vb;
short4 vd = va - vb;
short4 ve = __add_sat(va, vb);
short4 vf = __sub_sat(va, vb);
print_short4("va=", va);
print_short4("vb=", vb);
print_short4("vc=(va+vb)=", vc);
print_short4("vd=(va-vb)=", vd);
print_short4("ve=__add_sat(va,vb)=", ve);
print_short4("vf=__sub_sat(va,vb)=", vf);
return 0;
}
Compile:
%> cl7x -mv7100 -o1 -k vbif_ex.c -z -o vbif_ex.out -llnk.cmd
Run:
Load and run vbif_ex.out from the C7000 simulator to get the following result:
va= <1, 2, 3, -32766>
vb= <5, 32767, -13, 17>
vc=(va+vb)= <6, -32767, -10, -32749>
vd=(va-vb)= <-4, -32765, 16, 32753>
ve=__add_sat(va,vb)= <6, 32767, -10, -32749>
vf=__sub_sat(va,vb)= <-4, -32765, 16, -32768>
10 Removal of MISRA 2004 compiler command-line options
The C7000 C/C++ Compiler does not support MISRA 2004 checking as some other Texas Instruments compilers do. Therefore, the command-line options for MISRA 2004 checking have been removed and are no longer accepted by the compiler.
11 Silicon errata i2117 workaround support
The compiler option --silicon_errata_i2117
has been added to generate code that automatically works around silicon errata i2117. MMA performance may be negatively impacted by the use of this option in edge cases.
12 Half-float conversion intrinsics
Starting with the v1.4.1 compiler, half-float conversion intrinsics are supported, which map to appropriate C7000 half-float conversion instructions:
// VSPHP
uint = __float_to_half_float(float);
uint2 = __float_to_half_float(float2);
uint3 = __float_to_half_float(float3);
uint4 = __float_to_half_float(float4);
uint8 = __float_to_half_float(float8);
uint16 = __float_to_half_float(float16);
// VINTHP
uint = __int_to_half_float(int);
uint2 = __int_to_half_float(int2);
uint3 = __int_to_half_float(int3);
uint4 = __int_to_half_float(int4);
uint8 = __int_to_half_float(int8);
uint16 = __int_to_half_float(int16);
// VHPSP
float = __half_float_to_float(uint);
float2 = __half_float_to_float(uint2);
float3 = __half_float_to_float(uint3);
float4 = __half_float_to_float(uint4);
float8 = __half_float_to_float(uint8);
float16 = __half_float_to_float(uint16);
// VHPINT
int = __half_float_to_int(uint);
int2 = __half_float_to_int(uint2);
int3 = __half_float_to_int(uint3);
int4 = __half_float_to_int(uint4);
int8 = __half_float_to_int(uint8);
int16 = __half_float_to_int(uint16);
Each half-float in a vector register occupies the least significant 16-bits of a 32-bit vector element, with zero padding to 32-bits. Because the C and C++ language specifications do not define a half-float type and because only conversion instructions are supported by the C7000 architecture, **a vector of half-floats is represented with __uint vector where the __uint serves as a container for the half-float**. The following intrinsics may be used to load and store this representation efficiently:
__vload_unpack_int() [VLDHUNPKWU]
__vstore_packl() [VSTHSVPACKL]
13 Resolved defects
Resolved defects in v1.4.2.LTS:
ID | Summary |
---|---|
CODEGEN-8640 | Incrementing a volatile bit-field leads to corrupted code |
CODEGEN-8589 | Compiler intermittently crashes on switch with 20k cases |
CODEGEN-8579 | Software pipelined loop register allocation mistakenly assigns same register to conflicting variables |
CODEGEN-8563 | C7000 RTS memcpy and memset routines may trigger page fault exception |
CODEGEN-8538 | Compiler does not honor attribute aligned when applied to function |
CODEGEN-8485 | sscanf float conversion should fail and return 0 when input string starts with E or e |
CODEGEN-8458 | C6x intrinsics in C7000 Host Emulation have incorrect results |
CODEGEN-8454 | Streaming address generator (SA) advance may be removed as dead code |
CODEGEN-8451 | Streaming address generator (SA) advance may over-execute in software pipelines |
CODEGEN-8389 | Including cmath causes remark: zero used for undefined preprocessing identifier “STDC_VERSION” |
CODEGEN-7956 | Compiler incorrectly elides short-circuit behavior of && when right operand might invoke undefined behavior |
CODEGEN-7778 | Remove –asm_includes as CCS option |
CODEGEN-7499 | Host Emulation: __gmpy gives incorrect result (uchar variant) |
14 Known defects
Known defects in v1.4.x.LTS:
ID | Summary |
---|---|
CODEGEN-8620 | Remove integer divide and remainder functions from RTS |
CODEGEN-8576 | Loop that iterates a very large number of times causes compiler to fail with: Optimizer terminated abnormally |
CODEGEN-8075 | Vector pointer array access operator in host emulation causes memory use after free |
CODEGEN-7510 | __store_predicate_char intrinsic gives incorrect result in big endian |
CODEGEN-7509 | __vstore_reverse_bit variants reverse output of complex types in big endian |
CODEGEN-7503 | Host Emulation: __vsel_pvkv with float16 arguments gives incorrect results |
CODEGEN-7497 | Host Emulation: Use of complex matrix multiplies for cshort (full vector) produces incorrect results |
CODEGEN-6995 | __builtin_expect not supported yet on C7000 Compiler: Compiler fails with INTERNAL ERROR: no match for ICALL |
CODEGEN-6931 | Use of built-ins conversion suffixes: _sat, _rte, _rtz, _rtp, _rtn results in compiler error |
CODEGEN-6807 | Disassembler may not show sign extension of immediate values |
CODEGEN-6677 | C7x assembler core dumps on file with many asm() statements in C code |
CODEGEN-6509 | Compiler error: no instance of function template matches the argument list |
CODEGEN-6084 | –list_directory option should not be available on cl7x |
CODEGEN-2534 | Compiler terminates abnormally with incomplete complex initialization |
End Of File