New and Improved Diagnostics in MPLAB® XC Compilers

Each MPLAB^® XC compiler release strengthens diagnostics, so code that once built cleanly may now trigger new or stricter warnings. These diagnostics help you to improve your code quality but can increase the number of warnings you see.

If your project enables the -Werror (warnings-as-errors) option, that setting will block builds if your source code is seen as problematic by the new compiler diagnostics. This is especially true if you use the -Wall or -Wextra options to enable non-default diagnostics.

When you see the message "ccl: all warnings being treated as errors" in your build results, this is because your project is using -Werror, which tells the compiler toolchain to promote your warnings to errors. In this situation, you have several options:

1. Update your source code to address the warning
2. Remove the -Werror option to allow your build to proceed with all warnings displayed
3. Use the -Wno-error=<warning-type> to allow your build to proceed with the specific warning type

Add or Remove the -Werror Option in Your MPLAB® X IDE Project

Back to Top

Add or Remove the -Werror Option From Your Project in the MPLAB Extensions for Microsoft^® Visual Studio Code^® (VS Code)

Back to Top

MPLAB Code Configurator (MCC) Update Recommended

Projects generated by earlier versions of the MPLAB Code Configurator (MCC) forced -Wall (additional warnings) and -Werror (promote warnings to errors) options by default for MPLAB Harmony v3 projects. To improve compatibility with later compiler toolchain versions, MCC versions v5.6.3 and later no longer set these options by default.

If you are using code generated with MCC, we recommend upgrading MCC and regenerating your application code using this version of the tool. You can then re-enable -Wall and/or -Werror when you are ready.

Back to Top

About -Werror (Promoting Warnings to Errors)

-Werror stops warning debt from accumulating and keeps codebase clean as new features are added. It also amplifies security posture alongside higher warning levels, catching risky constructs early on. OpenSSF's guide explicitly encourages raising the floor on warnings and selectively promoting specific warnings to errors.

Why Does -Werror Create a Toolchain Version Dependency?

New compilers add new warnings, so old code that may have previously worked will fail. This scenario may be acceptable in personal development processes, however, this will create issues for others who try to build this code.

New release add or tighten warnings. The -Werror option turns those new warnings into hard failures even when the code's behavior does not change. This is a hidden dependency on "which compiler and which version," which is a common failure mode seen by embedded maintainers.

Enforcing -Werror on consumers of your code forces your own toolchain constraints onto their systems. The OpenSSf guidance is to keep the catch-all -Werror option for development. Users should not require it when distributing source. Instead, use the targeted -Werror=<name> option only for issues that should never be waived.

On day one for a new board, RTOS or library set, users often need a full warning report to triage. The -Werror option can block you before you can even see the list. The recommendation is to compile, collect warnings, fix them, and then re-enable the gate.

Back to Top

-Werror Best Practices

• Use the catch-all -Werror option during development and Continuous Integration (CI) workflows to prevent warning creep
• Avoid shipping source code that hard-requires -Werror
• Promote only specific must-fix warnings to errors with -Werror=<name> for release builds
• Development and Continuous Integration (CI) - Recommended Strong Mode
  • Enable high warnings (-Wall -Wextra plus project-specific add-ons)
  • Turn on -Werror in CI across supported compiler versions
  • Fail the build when any warning appears so new issues cannot creep in; this enforces "zero warnings" without hard-coding it into end-user builds
• Release builds and distributed source - Recommended Pragmatic Mode
  • Do not require -Werror
    • Instead, promote specific hazards to errors that you would never want to tolerate (e.g. -Werror=incompatible-pointer-types -Werror=int-conversion)
  • This will keep critical correctness issues non-negotiable while avoiding toolchain version lock-in
• Local developer builds - Migration Mode
  • If a new compiler version blocks your build due to fresh warnings, use one of these temporary fixes to get unblocked and then fix forward
    • Compile once with -Wno-error to surface the full warning list and prioritize fixes
    • Suppress a specific noisy diagnostic with -Wno-error=<name> , then remove it after remediation

Back to Top

Functional Safety Perspective

Treat the -Werror option as a process control that governs how you build and verify software, not as a product software requirement. This helps enforce coding rules and prevent regressions; however, it is not a standalone safety mechanism.

For safety products, document your toolchain version, warning policy and any suppressed diagnostics. Record each change when compilers or options shift, then run an impact analysis. Check to see if any new warnings appeared and if they were triaged.

This will make audits more tractable and keep builds reproductive even as diagnostics improve across MPLAB XC compiler versions.

Back to Top

External Resources and Further Reading

• Recommendations for when to use blanket -Werror, when not to, and which warnings to always promote to errors
  • OpenSSF Best Practices WG, Compiler Options Hardening Guide for C and C++
• Practical pitfalls of hard-requiring -Werror, and better enforcement via CI with optional toggles
  • “-Werror is Not Your Friend” (Embedded Artistry) by Phillip Johnston

Back to Top