TASKING TriCore v6.2r2 Inspector v1.0r1
This release note covers the initial features of the TASKING TriCore v6.2r2 Inspector v1.0r1.
Tricore v6.2r2 Inspector v1.0r1 is based on TASKING VX-toolset for TriCore v6.2r2.
Inspector operates identical to the VX-toolset (except for the issue detection) down to the Linker.
Generation of the final executable image by the Linker has been disabled.
Components of the VX-toolset dealing with the final executable image, library sources, examples have been removed from the product.
Components modified for the issue detection have been renamed with prefix insp_ (insp_cctc, insp_cptc, insp_ctc, insp_astc, insp_ltc).
By default, Inspector detects and reports full set of supported issues. The following options allow the user to customize this set:
--ignore=<issue-id>,... - disables detection of specified issues.
--detect=<issue-id>,... - disables detection of all issues and enables detection of specified issues only.
These options are supported by the Control Program, C/C++ Compiler, Assembler and Linker. Issue ID corresponds to issue's identification on the TASKING Issue Portal.
Inspector indicates issue detection by producing a warning message in two possible ways:
1. Definite detection.
Reported when Inspector can guarantee by detector's construction that processed code is affected by the triggered issue. Note that the affected code may still be removed from the final executable image by subsequent optimizations or linker - this requires verification by the user.
Example: ctc W999: [25/12] [INSP] detected occurrence of issue TCVX-43464.
2. Potential detection.
Reported when the issue is triggered, but Inspector can not guarantee that the processed code has been affected. Location and/or some additional information will be reported to facilitate verification by the user.
Example: ctc W998: [10/29] [INSP] detected potential occurrence of issue TCVX-43429.
Some potential detectors produce a lot of false positives. To narrow the processing, assembly comparison mode is introduced.
--detect-asm=<issue-id> - with this option Inspector only detects a single specified issue.
After initial potential detection Inspector generates two instances of assembly code - affected and not affected by the issue.
If comparison of these generated assembly files produces any meaningful difference, Inspector reports it and indicates locations of generated files for the further analysis.
Inspector supports separate logging of detection messages.
--insp-log=<file> - with this option all detection messages are duplicated into the specified file.
Log file is written in append mode and clearing it at the right moment is the user's responsibility
Logging mechanism supports concurrent writing for the multi-threaded build, but file locking over network is unreliable, so it shouldn't be used with a remotely located log file.
Available detectors for each tool are also listed if --detect option is used without an argument
- Assembler should by default make code sections at least 2 byte aligned
- LSL: prevent an allocation of the user stack in the PCP memory
- Linker allows cloned sections outside the available DSPR0 memory range
- AURIX multi-core: hex file does not contain code for cloned functions in ROM
- Issues with designated initializers for an element of an array of structs
- Optimization of struct return may lead to overlapping struct copy
- Linker misplaces .alignment_protection sections in reserved memory or a reserved section without notice
- Control program silently changes floating-point settings when --eabi-compliant option is used
- Compiler reorders memory accesses to potentially aliasing locations
- Compound literals generate incorrect code in recursive functions
- Perennial C P64072 fails on overlapping struct initialization
- C++ compiler option --eabi=H assumes a minimum alignment of 4 for a struct/union larger than 1 byte
- Sizeof operator applied to a VLA involving variable post-modification causes wrong code
- Linker does not insert alignment_protection sections when a group includes sections with a different alignment
- Incorrect alignment for bit-field of size 0 with --eabi=-char-bitfield
- Alignment for bit-field of size 0 does not conform to the TriCore EABI
- LSL reserved sections may be selected by select statements resulting in a corrupt internal linker state
- Copy table in output section overwritten by next section in output section
- Incorrect conversion of an if-else statement to an expression
- Reading elements of a const aggregate object as a larger type may result in an incorrect value.
- Non justified if condition optimization
- Bitfield of type "short int" or "long int" is treated as unsigned
- Run-time error for double _Complex expression passing to a function
- C compiler omits value assignment to pointer type function argument with forward store optimization enabled
- Compile-time concatenation of character string literal with unicode string literal fails
- Unroll small loops optimization leads to wrong code when speed tradeoff -t0 used
- C compiler - Generic Assembly Code optimization leads to false array index location in loop
- Incorrect reordering of volatile memory reads
- Linker may hang when the size of an output section is at least 2 MB
- AURIX 2G LSL files allow duplicate TriCore vector handlers to be located in SCR xram
- Linker ltc allows duplicate interrupt vectors to be located in vector table
- Invalid constant propagation with tripple indirection
- Include file may be skipped when same filename is included from different directories
- Missing initialization for local variable in a specific test case
- Incorrect conversion of _Complex type to _Bool
- Linker inserts section in an ordered, contiguous, fill group
- C compiler generates malloc call for variable length array
- Intrinsics __extracthwN and __extractbbyteN may return wrong result
- Loop invariant code optimization issue
- Linker - clone .text .clone code sections missing in copytable when using --non-romable option
- Large floating-point numbers become zero when converted to _Float16
- Wrong result multiplying two INIFINITY values when using software floating-point library
- Illegal double word access to SFR register range
- Compiler violates EABI due to 4 byte user stack frame generation
- MISRA C 2012 rule 10.4 checker reports false positive and fails to detect a violation
- Subnormal values may incorrectly compare equal to zero
- Erroneous code in code compaction function leads to invalid function parameter
- Compiler issues double word accesses for data located in MCS memory
- Wrong value is loaded into a 48-bit struct if used as a member of a larger 64-bit struct
- C compiler front-end may produce imprecise FP result (±1 bit difference)
- Compiler generates wrong code for loops with 64-bit iterators
- Incorrect use of a loop instruction
- Intrinsics __getbyteN and __gethwN may return wrong result
- Incorrect propagation of __pure__ function call result
TASKING products are protected with TASKING license management software.
You need a license key when you install a TASKING product on a computer. When you order a TASKING
product from TASKING or one of its distributors, a license key will be sent to you by email or on paper.
See the Getting Started with the TASKING Inspector for TriCore
guide for information on obtaining a license.
Local TASKING License Server (not applicable to evaluation licenses)
If you have ordered a TASKING product with a floating license, you can have it serviced by the
Remote TASKING License Server (the most convenient solution) or through a Local TASKING License Server
(in case you have no external network access for example). Consult your TASKING representative for
assistance on deciding what the best setup would be for your situation.
If you like to setup up a local license server, we kindly refer you for more information to
Support for TASKING License Management System (TLM)
on our website. Here you can also download the Local TASKING License Server package.
It is advised that you install the Local TASKING License Server
before you install products that require this server.