SonarQube CFamily fails to infer TI cl2000 target/macros on legacy C2000 project

SonarQube Server / Community Build
, ,
1

SonarQube CFamily fails to analyze a legacy TI C2000 project even though the project builds successfully and the build-wrapper / compilation database are generated correctly.

The analyzer starts the compilation units, but then fails with:

- target inferred as “x86_64-unknown-unknown”

- missing macros:

  • _SIZEOF_INT_

  • _SIZEOF_LONG_

  • _SIZEOF_LONG_LONG_

  • _SIZEOF_FLOAT_

  • _SIZEOF_DOUBLE_

  • _SIZEOF_LONG_DOUBLE_

- final error:

“Provided compiler is not compatible since missing macros cannot be inferred”

## Environment

- SonarQube Server version: 2026.1.2

- Edition: Data Center Edition

- Scanner executed from Azure DevOps pipeline

- Windows self-hosted build agent

- Legacy TI C2000 / DSP-BIOS project

## Baseline Reproduction Scenario

The cleanest reproducible scenario is with TI C2000 CGT 6.4.9:

- the project builds successfully,

- build-wrapper output is generated,

- compile_commands.json confirms that TI cl2000 6.4.9 is the actual compiler used,

- SonarQube still fails during CFamily analysis with the macro inference issue.

## What We Tested

### 1. Original toolchain

- TI C2000 CGT 6.0.2

- Project builds successfully

- SonarQube fails during CFamily analysis with missing __SIZEOF_* macro inference

### 2. Alternative toolchain

- TI C2000 CGT 6.4.9

- Project builds successfully

- compile_commands.json confirms cl2000 6.4.9 is used in real compilation units

- SonarQube still fails with the same macro inference issue

### 3. Additional experiment

- TI C2000 CGT 15.12.3.LTS

- This is not a valid Sonar baseline because the project itself fails to link due to a separate legacy DSP/BIOS compatibility issue:

  • undefined symbols such as HWI_RESET, HWI_INTx, PIE_INTx_y in nrdim_maincfg.cmd

- Because of that, we are not using 15.12.3.LTS as the main Sonar reproducible case

## Why We Believe This Is a CFamily Analysis Issue

We already verified that:

- the build succeeds with TI C2000 6.4.9,

- compile_commands.json contains the real compiler commands used by the project,

- build-wrapper output is generated correctly,

- the issue persists after changing toolchain from 6.0.2 to 6.4.9,

- the analyzer starts processing the compilation units but fails while inferring target/macros.

## Expected Result

SonarQube should analyze the TI C2000 compilation units successfully when provided with a valid build-wrapper output / compilation database from a successful build.

## Actual Result

SonarQube starts the CFamily analysis, but the compiler target falls back to “x86_64-unknown-unknown” and analysis stops because required compiler macros cannot be inferred.

## Potentially Related Historical Context

We previously observed a potentially related TI C2000 / Sonar CFamily issue where the analyzer appeared to use incorrect native type sizes, leading to false positives in rules depending on integer sizes and overflow behavior. The current issue seems to be in the same problem space, but more severe: analysis now fails earlier and ends with 0 files analyzed.

## Attachments

Please find attached:

buildlog-usingWrapper.txt (737.8 KB)

build-wrapper_6.0.2.log (7.8 MB)

compile_commands.json (4.0 MB)

build-wrapper-dump_6.0.2.json (4.8 MB)

## Request

Please help determine whether:

1. this is a known limitation or bug with TI cl2000 target inference in CFamily,

2. there is a recommended workaround,

3. or if additional compiler built-ins / predefined macros must be explicitly supplied for analysis.

4

Hi @thais_csc,

Thanks for the detailed report and for attaching the build-wrapper output and compilation database. that’s already very helpful.

What you’re describing lines up with a known limitation in how we handle older Texas Instruments compilers: the cl2000 compilers from the legacy C2000 CGT 6.x line don’t expose the __SIZEOF_* predefined macros (__SIZEOF_INT__, __SIZEOF_LONG__, etc.) when we probe them, so the analyzer can’t infer the native type sizes and stops with the “missing macros cannot be inferred” message. Newer toolchains report these macros and work out of the box.

Before I confirm that’s exactly what’s happening in your case, could you share the full debug analysis logs? To generate them, re-run the analysis with verbose logging enabled by adding:

-Dsonar.verbose=true

to your scanner invocation. Please attach the complete log output rather than a trimmed excerpt.

If you’re able to, a reproducer for a single failing file is the most direct way for us to investigate. You can generate one by adding this to the analysis properties:

-Dsonar.cfamily.reproducer=<path/to/one/failing/file.c>

Note that the path of the file needs to be the exact same path reported in the analysis logs.

This writes a sonar-cfamily.reproducer file next to your build-wrapper output, which you can share with us (privately if it contains proprietary code).

Let me know if you’d rather share these files privately. I can start a private thread for that.

Thanks,