TASKING TriCore v6.3r1  Inspector v1.0r8 Release Note

Scope

This release note covers the initial features of the TASKING TriCore v6.3r1 Inspector v1.0r8.

For release notes prior to v1.0r8, please visit the TASKING TriCore Inspector support website.

Contents

• Important Notices
• Build Numbers
• Tool Qualification
• Base Features
• Issues Detected in v1.0r8
• Issues Not Detected in v1.0r8
• Fixed Issues in v1.0r8
• License Information

Important Notices

TriCore v6.3r1 Inspector v1.0r8 is based on the TASKING VX-toolset for TriCore v6.3r1 patch 2. The Inspector operates identically 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 and 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).

You can use the TASKING Inspector v1.0r8 for the TASKING VX-toolset for TriCore v6.3r1 product and any of the patches, with the following restrictions:

• When you use the Inspector with the TriCore v6.3r1 product or with v6.3r1p1 applied, the Inspector does not detect issues fixed in TriCore v6.3r1p2.
• The level of confidence in the error detection of the Inspector is high if your software is compiled with the TASKING VX-toolset for TriCore v6.3r1p2 and degrades if other patch versions of the compiler are used.

To avoid build errors, the Inspector tools since v1.0r6 do now also accept the devices TC32x, TC3Ex and TC37xEXT which are supported after v6.3r1 patch 2.

The detector for issue TCVX-45218 has been improved since Inspector v1.0r7 to reduce the amount of false positives.

Introduced in Inspector v1.0r8

When MIL files (.mil, .ma, .ms) are identified, the Inspector C Compiler will give a warning that it cannot detect issues that were already introduced during a previous C/C++ to MIL translation phase. Therefore it is recommended to disable MIL linking when using Inspector tools to get the most accurate results.

The inspector will now also issue a message when there is no difference found after assembly comparison.

New options have been added to run assembly comparison automatically after a potential detection, see Detection by assembly comparison.

You can now disable all detectors for issues already fixed at a specified tool patch level, see Ignore issues at a specific patch level.

Build Numbers

All executable files in this release have the following build number: Build 25101508.

Tool Qualification

A series of verifications and tests have been implemented for each detector to ensure they are suitable for their intended purpose. All these verifications and tests have successfully passed for this release.

Base Features

Detection options

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 Issues Portal.

Detection messages

Inspector indicates issue detection by producing a warning message in the following ways:

1. Definite detection.

Reported when Inspector can guarantee by detector's construction that the 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 manual verification.

Example: ctc W999: [7/12] [INSP] detected occurrence of issue TCVX-44043.

2. Potential detection.

Reported when the issue is triggered, but Inspector cannot guarantee that the processed code has been affected. Location and/or some additional information will be reported to facilitate manual verification by the user.

Example: ltc W998: [2/51] [INSP] detected potential occurrence of issue TCVX-43994.

3. No detection.

When no issues are detected and option --msg-no-issues-detected is specified.

Example: [INSP] No definite or potential issues detected for the enabled list of detectors

Detection by assembly comparison

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 the assembly code - affected and not affected by the issue.

If the comparison of these generated assembly files produces any meaningful difference, Inspector reports it and indicates locations of the generated files for the further analysis.

To automatically run an assembly comparison after a potential detection, you can use option --compare-asm. With this option you do not need to run option --detect-asm for the detected potential issues one by one yourself, these are run automatically for the detectors which do support assembly comparison.

The following two options give you more control over where to save the assembly comparison results:

--compare-asm-subdir - save assembly comparison results into subdirectories, one subdirectory for each input file.

--compare-asm-directory=<path> - specify directory for saving assembly comparison results, instead of the current working directory.

Note: When using the control program insp_cctc together with assembly comparison, it is recommended to also use option --keep-temporary-files (-t); otherwise, the assembly comparison files might be renamed and/or ending up in a temporary directory determined by the operating system.

Ignore issues at a specific patch level

This option allows you to automatically ignore all detectors for issues already fixed at a specific patch level. This is useful if you use a higher patch level to build your application than what the Inspector product is based on.

For example: --patch-level=10 - ignores detection of all issues fixed in TriCore v6.3r1 patch 10.

Message logging

Inspector supports separate logging of detection messages.

--insp-log=<file> - with this option all detection messages are redirected to the specified file.

The log file is written in append mode and clearing it at the right moment is your responsibility.

The logging mechanism supports concurrent writing for the multi-threaded build, but file locking over network is unreliable, so it should not be used with a remotely located log file.

Issues Detected in v1.0r8

• Issue detection "Mixed" means: both "Definite" as well as "Potential" detection messages could be reported for that issue
• Available detectors for each tool are also listed if option --detect is used without an argument
• +) Detectors with a + prefix have been added in this release
• *) The inspector will report the detection of TCVX-45201, TCVX-45238 and TCVX-45344 always together, since these issues cannot be distinguished from each other. Although the detectors are listed as Potential, as a group the detection will be Definite. That means, at least one of the three issues triggered the detector definitely.

Issues Not Detected in v1.0r8

• TCVX-44325 - User stack pointer 4-byte aligned when interrupt occurs between FCALL and FRET
• TCVX-44047 - C compiler may leave empty .src file when it is killed
• TCVX-44577 - Wrong BMHDx_BMI masks for AURIX 2G in tc1v1_6_2.bmhd.lsl
• TCVX-44758 - FP operations involving INF or NAN inputs may produce wrong results with --fp-model=sT
• TCVX-44962 and TCVX-44835 - Struct alignments for bit-fields not always EABI compliant
• TCVX-44770 and TCVX-45075 - Non-trapping software-emulated floating-point operations do not handle exceptional results correctly
• TCVX-44891 - Software-emulated 32-bit floating-point multiplication may yield 0.0f instead of FLT_MIN
• TCVX-45129 - Floating point comparison operations do not raise FE_INVALID when two NAN values are compared

These issues have been deemed impossible to detect in any meaningful way during compilation. User Guide contains a detailed description of the situation when the issue might occur and how to prevent it.

Fixed Issues in v1.0r8

• INSPTC63R1-39 - Unexpected behavior of --detect-asm flag

License Information

TASKING products are protected with TASKING license management software.

License key

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 TASKING License Management (TLM) Support page for information on obtaining a license.

Improved Verbose Logging

You can set the TSK_LOG_VERBOSE option in licopt.txt, or as an environment variable, to different verbose levels.

With level 3 or higher, detailed license configuration information is shown, which is useful for debugging licensing problems. For example, it shows the environment variables or options used, the license key and the search path.

Support for wait for a free license

You can set the TSK_LICENSE_WAIT option in licopt.txt to a configurable time period to wait for a free license seat to become available instead of directly terminating when a license request is denied.

See section Wait for a Free License in the TASKING License Management online documentation.

Wait for Available Process

If your license specifies a maximum number of processes you are allowed to use, you can set the TSK_PROCESS_WAIT option in licopt.txt, or as an environment variable, to the parallel process time-out (default: unlimited). This specifies the number of seconds the system is allowed to wait for a process to run if the maximum number of parallel processes permitted by the license is already running.