Description
When using the 2025.10 version of the toolchain with zcmt (a sub-extension of the RISC-V zc extensions, which includes zca (Code Size Reduction A), zcb (Code Size Reduction B), zcmp (Code Size Reduction with Push/Pop), and zcmt (Code Size Reduction with Table Jump)), there is a transitive dependency issue at the linking stage that can cause zcmt to be generated even when it is not intended for the project.
Current Behavior
The zcmt extension is currently generated during the linking phase. When a project links against a custom library (.a archive), if the library was compiled with zcmt enabled but the project's architecture parameter (arch) is configured without zcmt (e.g., modified in the IDE settings), zcmt is still unexpectedly generated in the final output.
Example Scenario
Text
Main Project: arch=riscv32-imac (without zcmt)
↓ links to
Custom Library: compiled with arch=riscv32-imac_zcmt (with zcmt)
↓ result
Unexpected Behavior: zcmt code generation occurs despite project arch lacking zcmt
Root Cause
The zcmt feature exhibits transitive properties by design. Once any object file or archive in the linking process has zcmt enabled, the toolchain assumes the entire project uses zcmt and propagates this capability through the linking stage. This transitive behavior is inherent to the current zcmt implementation design.
Workaround / Solutions
To avoid unexpected zcmt generation, maintain consistency across the build:
If using zcmt: Both the library and the project compilation options must include zcmt in their architecture parameters (e.g., arch=riscv32-imac_zcmt)
If NOT using zcmt: Ensure that the libraries are also compiled without zcmt in their architecture settings
Best Practice: Keep library and project compilation architecture flags aligned to avoid mismatches
Environment
Toolchain version: 2025.10
Architecture: RISC-V
Extensions: zc extensions (zca, zcb, zcmp, zcmt)
Phase affected: Linking stage
Additional Information
This behavior change was introduced because the 2025.10 toolchain includes zcmt generation functionality by default. The versions before 2025.10 are fine because zcmt does not generate automatically. Users migrating from previous toolchain versions or integrating libraries from different sources may encounter this issue if architecture flags are not properly synchronized.
Description
When using the 2025.10 version of the toolchain with zcmt (a sub-extension of the RISC-V zc extensions, which includes zca (Code Size Reduction A), zcb (Code Size Reduction B), zcmp (Code Size Reduction with Push/Pop), and zcmt (Code Size Reduction with Table Jump)), there is a transitive dependency issue at the linking stage that can cause zcmt to be generated even when it is not intended for the project.
Current Behavior
The zcmt extension is currently generated during the linking phase. When a project links against a custom library (.a archive), if the library was compiled with zcmt enabled but the project's architecture parameter (arch) is configured without zcmt (e.g., modified in the IDE settings), zcmt is still unexpectedly generated in the final output.
Root Cause
The zcmt feature exhibits transitive properties by design. Once any object file or archive in the linking process has zcmt enabled, the toolchain assumes the entire project uses zcmt and propagates this capability through the linking stage. This transitive behavior is inherent to the current zcmt implementation design.
Workaround / Solutions
To avoid unexpected zcmt generation, maintain consistency across the build:
If using zcmt: Both the library and the project compilation options must include zcmt in their architecture parameters (e.g., arch=riscv32-imac_zcmt)
If NOT using zcmt: Ensure that the libraries are also compiled without zcmt in their architecture settings
Best Practice: Keep library and project compilation architecture flags aligned to avoid mismatches
Environment
Toolchain version: 2025.10
Architecture: RISC-V
Extensions: zc extensions (zca, zcb, zcmp, zcmt)
Phase affected: Linking stage
Additional Information
This behavior change was introduced because the 2025.10 toolchain includes zcmt generation functionality by default. The versions before 2025.10 are fine because zcmt does not generate automatically. Users migrating from previous toolchain versions or integrating libraries from different sources may encounter this issue if architecture flags are not properly synchronized.