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,

5

sonar-cfamily-debug_NEW.zip (3.2 MB)
Hi Mostafa,

Thanks for the follow-up!

I re-ran the analysis using verbose mode and generated the reproducer as requested, follows attached.

Thanks,

Kind regards,

6

Hi @thais_csc,

Thanks a lot for the debug logs and the reproducer.

We were able to confirm the probe situation: the older C2000 toolchain (in your case cl2000 6.4.9) doesn’t report the __SIZEOF_* macros when we probe it, so the analyzer can’t infer the native type sizes and stops. We already have a ticket tracking this for older TI compilers, and I’ve updated it with the details from your post. Once it’s addressed we’ll update this thread. We can’t commit to a timeline at this point.

I also see you’ve already found the right workaround, which is to provide the missing macros directly in your build command via --define. Those values are appended to the probe results, so they fill in what the compiler doesn’t report.

One heads up on that workaround. The C2000 uses a 16 bit byte (so sizeof(int) is 1), while our analyzer currently assumes an 8 bit char and reads __SIZEOF_* in 8 bit units. This means the values you provide are interpreted as bit width divided by 8, and the word based values (int=1, long=2, …) end up modeling the types at half their real width. If you want the widths to match the hardware, use bit width / 8 instead (int=2, long=4, long long=8, float=4, double=4, long double=8). Even then, the 16 bit char itself can’t be fully modeled yet, so a few rules that depend on byte size may still misbehave on this target. That part is covered by a separate improvement we’re tracking.

If you notice specific rules raising odd issues after adjusting the values, Please let us know.

Thanks,

9

Hi Mostafa,

Thanks for the clarification!

We updated the workaround with the 8-bit-unit values recommended by SonarSource:

_SIZEOF_INT_=2

_SIZEOF_LONG_=4

_SIZEOF_LONG_LONG_=8

_SIZEOF_FLOAT_=4

_SIZEOF_DOUBLE_=4

_SIZEOF_LONG_DOUBLE_=8

The values are now present in compile_commands.json, and the CFamily analysis completes successfully.

This works as a temporary workaround, but we would still expect SonarSource to fix the underlying limitation so older TI C2000/cl2000 toolchains can be analyzed without manually defining these macros.

Please keep us updated on the internal ticket and the plan for a permanent fix.

Thanks,

Thais