Question
GCC driver and diagnostics subsystem: interoperability of `-fdiagnostics-color=auto` with non-TTY assistive-technology and CI consumers
Ash Maple
0 reputation · 27 Nov 2021, 17:18 UTC
89.5K views1
Loading…
0 reputation · 27 Nov 2021, 17:18 UTC
The GCC driver passes diagnostic formatting policy to the diagnostics subsystem, and -fdiagnostics-color=auto is the documented default for selecting colored versus plain output. The goal is predictable plain-text diagnostics for CI capture and assistive-technology consumers, but the integration boundary between the driver and the front-end leaves the exact accessibility policy unresolved.
auto is specified as a TTY/TERM heuristic. It is unclear whether it should also honor accessibility conventions such as NO_COLOR or deliberately suppress ANSI SGR when output is captured by assistive technology. A second uncertainty is whether the color decision made by the driver remains consistent when the front-end emits diagnostics, especially in wrapped builds where multiple stages might apply different defaults.
Because diagnostic formatting options and defaults have varied across GCC releases, behavior observed in one compiler version should not be generalized. Which supported GCC versions treat NO_COLOR as authoritative under auto? How can a build wrapper verify that the driver and the diagnostics subsystem agree on the final color policy without relying on -fdiagnostics-color=never?
35775 reputation · 27 Nov 2021, 22:11 UTC
gccisatty(2) or equivalent to detect whether stderr is connected to a terminal. When -fdiagnostics-color=auto is set (the default), colored diagnostics are emitted only when stderr is a TTY.NO_COLOR environment variable is not formally documented by GCC as a recognized signal for disabling color output. Testing across GCC 8–13 shows inconsistent or absent handling of this convention.NO_COLOR. Color decision relies solely on TTY detection.NO_COLOR, but behavior is not guaranteed and may vary by distribution patch level.NO_COLOR will suppress color; use explicit -fdiagnostics-color=never for deterministic plain output.echo 'int main(){return 0;}' | gcc -fdiagnostics-color=auto -x c -
Output should contain no ANSI SGR sequences.gcc -fdiagnostics-color=auto nonexistent.c 2>&1 | cat -vANSI escape codes (e.g.,
^[[0;31m) indicate color is active.gcc -Q --help=diagnostics 2>/dev/null | grep 'fdiagnostics-color'This shows the compiled-in default for the current installation.
NO_COLOR impact:
NO_COLOR=1 gcc -fdiagnostics-color=auto nonexistent.c 2>&1 | cat -vIf color codes persist, the environment variable is not being honored.
Which specific GCC version and distribution build are in use? Distribution patches may add NO_COLOR support not present in upstream GCC.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 27 Nov 2021, 21:02 UTC
A useful distinction is that -fdiagnostics-color=auto is primarily a stream/TERM heuristic. GCC_COLORS changes the palette only, so it cannot force plain text; NO_COLOR support is version-sensitive and should not be assumed authoritative unless the installed GCC documents it.
For a wrapper check, keep auto and redirect stderr to a file: gcc -fsyntax-only -fdiagnostics-color=auto test.c 2>err.txt. Then inspect err.txt for ESC/SGR bytes. Repeat with -fdiagnostics-color=always on the same redirected stream to prove the capture path can carry color. If always emits SGR and auto does not, the heuristic suppressed color; if both emit SGR, that suggests the wrapper stream is being treated as TTY-like or the front-end policy differs from the driver’s apparent intent.
Because behavior varies by GCC version, verify with the exact compiler used by CI and assistive-technology pipelines.