TASKING SmartCode v10.2r1
Release Note

Scope

This release note covers the release of version v10.2r1 of TASKING SmartCode. For release notes prior to v10.2r1, please visit the TASKING SmartCode support website.

Contents

• Important Notices
• Build Numbers
• New in v10.2r1
• Fixed Issues in v10.2r1
• Quick start
• License information

Important Notices

This is the second public release of TASKING SmartCode which supports Infineon's AURIX TC4xx series.

The product includes the following features:

• TASKING SmartCode contains the toolsets for TriCore, ARC (PPU), 8051 (SCR) and MCS (GTM).
• The ARC/PPU toolset compiles code that is intended to run on the ARC/PPU which employs Synopsys DesignWare ARC EV7x Processor IP.
• The ARC/PPU toolset supports both ARCv2 baseline and Vector DSP Instruction Set Architecture.
• TASKING SmartCode supports all AURIX TC4x devices that are currently available.
• The ARC/PPU debugger is included in the product, but there is currently no debug target in the product available to debug your ARC project. The Synopsys Metaware Simulator must be purchased from Synopsys separately.
• TASKING SmartCode supports the iSYSTEM debugger and this debugger can be started from the TASKING Eclipse environment.
  • Note 1: The iSYSTEM debugger included in the product will be installed the first time you create a new debug configuration. You can also start the installation manually. From the Window->Preferences dialog, select iSYSTEM and click the Install button. This Install button changes into an Update button after installation is done. The Update button is enabled when a new version of the iSYSTEM debugger is available.
  • Note 2: The iSYSTEM debugger is not supported under Linux.
• The safety manuals for the TriCore and ARC toolsets are included in the product.
• TASKING SmartCode is a 64-bit product. It shall be installed on 64-bit versions of the Windows operating system. The release has been tested on Windows 7 64-bit and on Windows 10 64-bit, using the included simulator of Infineon.
• TASKING Eclipse plugins support all toolsets included in the product.
• The Eclipse/CDT distribution version 2023-03 is shipped with the product.
• The Eclipse/CDT distribution includes a plugin containing the JustJ Java Runtime Environment. This JRE will be used during the excution of the TASKING Eclipse environment.

Build Numbers

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

New in v10.2r1

TriCore toolset updates

TriCore C++ compiler improvements and optimizations

• The EDG C++ front-end was updated to version v6.3.
• The C++ Library was updated to LLVM release v14.0.6.
• The following TriCore C++ compiler options are considered superfluous and are removed from the product:
  • --anachronisms
  • --auto-type
  • --c++11-sfinae
  • --compound-literals
  • --delegating-constructors
  • --dollar
  • --lambdas
  • --namespaces
  • --no-auto-storage
  • --no-auto-type
  • --no-bool
  • --no-extern-inline
  • --no-namespaces
  • --no-nonconst-ref-anachronism
  • --no-nullptr
  • --no-rvalue-refs
  • --no-typename
  • --no-wchar_t-keyword
  • --nonconst-ref-anachronism
  • --nonstd-default-arg-deduction
  • --nonstd-instantiation-lookup
  • --nonstd-using-decl
  • --nullptr
  • --old-for-init
  • --old-line-commands
  • --old-specializations
  • --preserve-lvalues-with-same-type-casts
  • --rvalue-ctor-is-not-copy-ctor
  • --rvalue-refs
  • --uliterals
  • --unrestricted-unions
  • --user-defined-literals
  • --variadic-macros
  • --variadic-templates
  • --base-assign-op-is-default
  • --c++11-sfinae-ignore-access
  • --default-nocommon-tentative-definitions
  • --deprecated-string-conv
  • --friend-injection
  • --guiding-decls
  • --implicit-include
  • --incl-suffixes
  • --long-lifetime-temps
  • --multibyte-chars
  • --no-c++11-sfinae
  • --no-c++11-sfinae-ignore-access
  • --no-class-name-injection
  • --no-const-string-literals
  • --no-dep-name
  • --no-distinct-template-signatures
  • --no-explicit
  • --no-for-init-diff-warning
  • --no-variadic-macros
  • --nonstd-anonymous-unions

TriCore C compiler improvements and optimizations

• The TriCore C compiler supports the ISO/IEC 9899:2018 (C17) language standard.
• The TriCore C compiler supports the new TC4xx instructions: DIV64, DIV64.U, LSYNC, REM64, REM64.U and TRAPINV.
• The TriCore C compiler supports option --silicon-bug=cpu-tc141 to avoid using these new instructions, since the TC49xA device does not support them.
• The TriCore C compiler supports new intrinsics:
  • volatile void __lsync( void );
  • volatile void __trapinv( void );
• Cyber security related improvements:
  • The TriCore C compiler gives a warning if a global variable is removed due to optimizations. This warning is given when new option --warning-level is set to level 2.
  • The TriCore C compiler gives a warning if a condition is known at compile time. This warning is given when new option --warning-level is set to level 2.
  • The TriCore C compiler supports two new intrinsics, one to check the sticky overflow/underflow bit in the TriCore Program Status Word (PSW) and one to clear the sticky bit:
    - volatile void __trapsv( void );
    - volatile void __rstv( void );
  • The tools log the used environment variables settings in the note sections of the generated object files. You can view note sections by using the -F0n option of the hldumptc tool.
• The TriCore C compiler supports options --no-strict-overflow and --no-strict-aliasing to disable certain optimizations that are based on the absence of undefined behaviour.
• The TriCore C compiler supports option --section-anchors to enable generation of section anchors.
• The TriCore C compiler combines multiple operations on single bits into one single operation on multiple bits.
• The TriCore C compiler has a new optimization to perform simple loop unrolling.
• The TriCore C compiler transforms nested loop into one single extended loop.
• The TriCore C compiler schedules unconditional instructions after conditional jumps.
• The TriCore C compiler performs local IPRO and FCALL/FRET substitution.
• The TriCore C compiler generates in situ code for strcpy() of a string constant.
• The TriCore C compiler generates in situ code for memcpy and memset calls.
• The TriCore C compiler always use bitfield integer type dependent instructions to access a volatile defined bitfield.
• The TriCore C compiler issues a warning for an undefined macro.
• The TriCore C compiler was made consistent with preprocessing.
• The TriCore C compiler performs various control flow simplifications.
• The TriCore C compiler got rid of unfavorable sequences involving one or more 'extr' instructions.
• The TriCore C compiler does not schedule quad-word loads and stores shortly before a loop instruction.
• The TriCore C compiler optimizes highly inefficient code generation for half-word aligned struct copying.
• The TriCore C compiler gives a warning for improper initialization due to unintentional lack of completeness, i.e. "too few initializers".

TriCore linker updates

• The LSL files provide an optional fill pattern for unused non-reserved read-only program memory, with the TRAPINV opcode as the default. You can set the macros __FILL_UNUSED_FLASH and __FLASH_FILL_PATTERN to activate this feature.
• The linker by default uses dspr0 for core 0 variables.
• The linker allows multiple defined absolute symbols with the same value.

Debugger updates

• The SmartCode product supports the iSYSTEM debugger and this debugger can be started from the TASKING Eclipse environment. Note however, that the iSYSTEM debugger is not supported under Linux.
• The hardware debugger supports the Infineon TriBoard for TC49x.
• The SmartCode product is prepared to include the Synopsys nSIM Simulator. In section 7.2 Debugging an ARC Project of the ARC/PPU User Guide it is explained how this can be achieved.

ARC toolset updates

ARC C++ compiler improvements and optimizations

• The ARC C++ compiler has been added to the product including the C++ Standard Library.

ARC C compiler improvements and optimizations

• The ARC C compiler supports vgather and vscatter operations on the vector types with 16-bit and 8-bit lanes.
• The ARC C compiler improved on ABI compliance by making %r25 callee-saved registers and not caller-saved and by setting the vector stack alignment according to the ABI.
• The ARC C compiler's in-line assembler supports predicated instructions.
• The ARC C compiler supports non-native vNx2int_t, vNx4int_t and vNx4short_t data types.
• The ARC C compiler supports intrinsics and data types for double word accumulator.
• The ARC C compiler supports additional auto-vectorization scenarios:
  • a loop with non-unit iteration counter.
  • a loop with loop iterator induction.
  • a loop with non-basic floating point operators.
  • a vectorization of reduction operations.
• The ARC C compiler changed vector comparison types to be compatible with the MetaWare compiler.
• The ARC C compiler supports non-constant vector subscripts.
• The ARC C compiler supports ternary operator ?: on vector types.
• The ARC C compiler supports new intrinsics for:
  • double word accumulator.
  • vector element shifts and shuffles on floating-point vectors.
  • predicated vvffadd instruction.
  • vector types reinterpretation.
  • vector predicate instructions: vvpinit, vvpmovps, vvpall, vvpany.
  • vector load and store with bit-reverse addressing mode.
  • system instructions: dsync, dmb, prealloc, prefetchw.
• The ARC C compiler improved scalar core optimizations:
  • Implemented a GLO pass to optimize load after store to the same address.
  • Implemented a GLO pass to optimize operations using arithmetic properties.
  • Improved loop code generation by:
    • Supporting conditional LPcc instruction.
    • Supporting instruction DBNZ.
    • Fixing redundant calculation of LP_COUNT.
    • Using LP for an outer loop.
  • Improved MAC code generation.
  • Improved code generation division by constant.
  • Improved double load/store optimization.
  • Improved switch jump table code generation.
  • Increased aggressiveness of the loop unroller.
  • Improved tail-call optimization.
  • Enabled caller-saves register promotion.
• The ARC C compiler improved vector core optimizations:
  • Improved the ARC pipeline scheduling model.
  • Added missing vvld and vvst scalar addressing modes.
  • Added an auto-vectorization pass to recognize vvci patterns.
  • Added peephole patterns to generate predicated predication instructions.
• The ARC C compiler improved on the loop variant optimization of pointer dereference.

ARC assembler updates

• The ARC assembler supports the option --assume-short to allow 16-bit encoding even if the mnemonic is not specified with _S suffix in code.
• The ARC assembler supports bundle validation checks on super instructions and bundle specifications.

Other noteworhty updates

• SmartCode v10.2r1 is protected by one license key only, as opposed to version v10.1r1. The license for the SmartCode standard edition (product code: 07-200-260-804) protects the TriCore, ARC (PPU),8051 (SCR) as well as the MCS (GTM) toolset.

Fixed Issues in v10.2r1

• SMRT-158 - Compiler error ctc S911 with MISRA rule 10.3
• SMRT-171 - SW implementation of C standard library function fmaf() does not raise FE_INVALID for signaling NAN
• SMRT-199 - Misleading 'ctc E350: invalid constraint for parameter 1' error indicating wrong parameter number
• SMRT-243 - C compiler: MISRA C 2012 rule 3.2 - false positive error for line splicing
• SMRT-277 - C compiler: wrong code generation for float-to-int conversion when using #pragma STDC FENV_ACCESS ON: no FE_INVALID is raised
• SMRT-281 - Constant propagation optimization may violate #pragma STDC FENV_ACCESS ON
• SMRT-282 - Control flow simplification optimization may violate #pragma STDC FENV_ACCESS ON
• SMRT-286 - Atomic load is removed in some cases
• SMRT-287 - 8051 compiler: Conditional illegal sequential load of volatile address
• SMRT-292 - C compiler: MISRA C 2012 rule 18.8 erroneously flags violation of variable-length array
• SMRT-298 - Conversion double-to-float may produce 0 instead of FLT_MIN
• SMRT-312 - Function @FLD accepts negative arguments with undefined behavior
• SMRT-319 - S911 error when any MISRA C 2012 rule check for rules 10.x is enabled
• SMRT-328 - Erroneous code generation due to loop fusion optimization
• SMRT-329 - Struct parameter passing error in a va_arg use case
• SMRT-334 - PPU copytable processing causes ECC memory issues on TC49x hardware
• SMRT-335 - FPU instructions may corrupt 64-bit integer computations
• SMRT-338 - Non EABI compliant bitfield offset used in a struct with a structsize larger than 32 bit
• SMRT-343 - C compiler: incorrect integer promotion using expression simplification optimization
• SMRT-345 - C compiler: missing truncation for cast that is converted to _Bool
• SMRT-347 - S911 internal consistency check failed error when using a VLA in a function call
• SMRT-358 - C++ Compiler: Non EABI compliant bitfield offset used in a struct
• SMRT-359 - DSP-C: operations on __sfract / __wrap __sfract may produce incorrect results
• SMRT-360 - Missing zero-extend for indirect store to _Bool automatic variable
• SMRT-362 - C compiler: Incorrect CSE of VLA size expression
• SMRT-363 - C compiler: flexible array member initialization: diagnostics may be missing
• SMRT-367 - Incorrect vectorization of small loop with unsigned iterator
• SMRT-377 - Compiler ignores variable value change after this has been passed by reference in a function call
• SMRT-388 - Compiler overwrites a complete byte in a bitstruct whereas only two bits are modified
• SMRT-393 - Wrong code generation for an if-else statement
• SMRT-394 - Erroneous code generated for C++ code using __disable_and_save and __restore intrinsics
• SMRT-395 - Wrong symbol value for empty copy table sub-table
• SMRT-396 - Auto-vectorization may produce an "infinite" loop
• SMRT-398 - Memory access trap due to empty copy table for core1
• SMRT-399 - C51 assembler: missing diagnostics for sfr bit type expressions
• SMRT-401 - Erroneous code generation due to incomplete address register initialization
• SMRT-406 - C compiler error S900 internal consistency check failed - please report
• SMRT-407 - User stack demand higher than calculated by the C compiler
• SMRT-413 - Default near allocation is not disabled for floating point libraries
• SMRT-417 - Linker feature --whole-archive ignores object modules without exported symbols
• SMRT-425 - Struct alignments for bit-fields not always EABI compliant
• SMRT-426 - Incorrect alignment of vstack
• SMRT-427 - Control program: incorrect handling of -L option without argument
• SMRT-430 - Linker assigns two PPU variables to the same memory location incorrectly
• SMRT-436 - C compiler: unexpected "Assertion failed" when using _Alignas for an object with block scope
• SMRT-437 - Compiler issues ld.dd instructions to read data from EEPROM (DFLASH) memory which is not permitted
• SMRT-447 - Optimization ignores __weak__ attribute in the code
• SMRT-449 - LSL macro NOXC800INIT is not documented
• SMRT-451 - C compiler error S917: internal consistency check failed - please report
• SMRT-453 - MISRA C:2012 rule 5.3 violation when math.h and libfloat.h are included
• SMRT-459 - Overlapping sections created when a reserved section is used with a memory fill entry
• SMRT-471 - Example included in chapter 7.9.12. Stack Size Estimation is erroneous
• SMRT-479 - ARC return of struct in register falls through
• SMRT-491 - Trap encountered when debugging an elf file while the hex file works normal
• SMRT-492 - Loading specific ELF file in the debugger takes a long time to complete
• SMRT-496 - C Compiler: _Bool - incorrect expression evaluation
• SMRT-497 - Compiler conducts a signed division instead of an unsigned one in a specific use case
• SMRT-500 - C compiler ignores cast in a specific use case for a function return value
• SMRT-502 - Compiler: incorrect return value
• SMRT-508 - Copy table processing for other cores than core 0 causes a bus trap
• SMRT-509 - C compiler may leave empty .src file when it is killed
• SMRT-514 - Header file setjmp.h - MISRA C check disabling not restored to default
• SMRT-515 - Erroneous code when loading a _Bool type variable into a char type using a _Bool pointer in an inline function
• SMRT-522 - Generate debug information for used symbols only
• SMRT-528 - Compiler generates wrong code for loops with 64-bit iterators
• SMRT-538 - User stack pointer 4-byte aligned when interrupt occurs between FCALL and FRET
• SMRT-540 - Flow optimization causes missing read operation
• SMRT-543 - Compiler carc misses check for __vccm pointer qualifier
• SMRT-549 - Wrong ABS pattern optimization for float or double
• SMRT-551 - Tool elfstrip breaks weak definition replacement for references in same object file
• SMRT-556 - Invalid strength reduction for subscript with unsigned wraparound
• SMRT-559 - DSP-C: Constant folding involving fixed-point types may produce incorrect results
• SMRT-560 - Wrong bit-field alignment for a short type member of a struct
• SMRT-561 - Stack is not initialized for some __channel functions with run-time library calls
• SMRT-568 - PPU uncached variables are accessed from TriCore side via cached addresses
• SMRT-570 - Forward store optimization for weak variable causes NULL pointer dereference
• SMRT-572 - PPU C compiler does not generate instructions bypassing the cache
• SMRT-575 - Only the first quarter of the PPU image is copied by _ppu_init routine
• SMRT-578 - MISRA global rules are not checked when only one module is supplied
• SMRT-579 - An atomic_flag type variable (stdatomic.h) ends up in cached memory
• SMRT-583 - Call graph not correct for aliases
• SMRT-586 - Loop invariant code optimization issue
• SMRT-587 - Wrong iterator values after jumping into loop
• SMRT-589 - MOVL optimized out even when zero status bit is significant
• SMRT-592 - Evaluation of floating expressions involving NaN may produce wrong results
• SMRT-594 - Compiler conducts a signed modulo calculation instead of unsigned
• SMRT-599 - Memory access out of bounds due to a missing conversion of the loop increment
• SMRT-601 - Absolute placement of sda group fails due to erroneous arch_ppu.lsl LSL file content
• SMRT-608 - Incorrect constant propagation
• SMRT-609 - C compiler c51 generates wrong code
• SMRT-621 - Compiler generated code reads from uninitialized stack address
• SMRT-622 - Erroneous code for XOR assignment in a nested loop
• SMRT-623 - C compiler ignores cast in a specific use case for a function return value
• SMRT-635 - Compiler generates ld.da/st.da instructions for copying 8-byte structs in peripheral memory
• SMRT-640 - Software FP implementation of float16 type conversion does not raise inexact exception on overflow
• SMRT-652 - C compiler generates incorrect array index values

• TLM specific fixes:
  • Clients configured to use joined licenses via the special license key "PRODUCT" cannot be borrowed. Please note, that the new license pool mechanism is the preferred way now to group multiple licenses instead of using "PRODUCT".
  • Licborrow reports the requested number of days as granted even if this is limited by the license server
  • Licborrow diagnostic message on the Check License button is not clear
  • Uninstall should remove license environment variable

Quick Start

For a quick start, just start the IDE from the Start menu. This will start the Eclipse based development environment. You will be asked to select a workspace. In case you used Eclipse before it is recommended to select a new workspace. After clicking OK, you will see the 'Welcome' view. On this view you will see icons that link to specific information.

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.

License pool mechanism

You can now define a named pool of specific licenses on the local license server.

A license pool is useful to specify that the licenses for one or more products shall be grouped together. This can be the case for example when your license agreement has constraints on geographical location, such as a single site license, country license or continental license. In that case you can put all product licenses that are allowed to be used by a specific location into a license pool.

Pool names for TASKING products released after March 2023 have the syntax POOL-name, where the name is free to choose from 1 up to 14 characters. Pool names are also supported with existing TASKING products, as long as you use the new local license server and specify the pool names in the fixed format POOL-xxxx-xxxx-xxxx.
Note that you also need to use this fixed pool name format if you are mixing older and newer TASKING products.

The PRODUCT keyword has been deprecated, but still works for backwards compatibility.

Support for wait for a free license

You can now 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.