GCC y Clang comparados

GCC y Clang implementan el mismo estándar, pero no son intercambiables. Nacieron de proyectos con objetivos distintos, tienen representaciones internas incompatibles y llegan al mismo binario por caminos que divergen en lo que ven, en lo que avisan y en lo que perdonan. Elegir uno no es cuestión de gusto: es una decisión de ingeniería. Usar los dos a la vez, casi siempre, es la decisión correcta.

Dos linajes, dos arquitecturas

GCC (1987) es un compilador monolítico por diseño. Su cadena interna baja el código fuente a GENERIC, luego a GIMPLE en forma SSA —donde vive casi toda la optimización de alto nivel— y por fin a RTL, muy cercano a la máquina. Esa arquitectura cerrada fue una decisión deliberada del proyecto GNU: dificultar que alguien reutilizara el front-end para construir herramientas propietarias sobre él.

Clang (2007) hizo lo contrario. Es un front-end concebido desde el primer día como biblioteca: construye un AST de alta fidelidad que conserva la forma exacta del código fuente —comentarios, macros, posiciones, paréntesis redundantes— y solo después lo baja a LLVM IR, una representación tipada, textual y reoptimizable.

flowchart LR
S[Codigo fuente C23] --> G[Front-end GCC]
S --> C[Front-end Clang]
G --> GI[GENERIC y GIMPLE SSA]
GI --> R[RTL]
R --> B1[Binario]
C --> AST[AST de alta fidelidad]
AST --> IR[LLVM IR]
IR --> B2[Binario]
AST --> T[clangd clang-tidy clang-format]
IR --> SAN[Sanitizers y LTO]
style T fill:#a6e3a1,color:#11111b
style SAN fill:#a6e3a1,color:#11111b

La consecuencia práctica es enorme y no está en el binario: está en el ecosistema. clangd, clang-tidy, clang-format y los sanitizers existen porque el AST de Clang es reutilizable. GCC ha respondido con -fanalyzer y con complementos, pero el tooling estructural sigue viviendo en LLVM.

Diagnósticos: el terreno donde compiten

Clang popularizó el diagnóstico moderno: cursor de intercalación, rangos subrayados y sugerencias de corrección aplicables (fix-its). GCC alcanzó ese nivel y en algunas áreas lo superó. Hoy la comparación es más fina.

-fanalyzer de GCC es el arma pesada menos conocida del ecosistema: hace análisis simbólico sensible a rutas y detecta doble free, fugas, uso tras liberar y desreferencias nulas sin ejecutar el programa, imprimiendo el camino completo de llamadas que lleva al fallo. -Wthread-safety de Clang no tiene equivalente en GCC: verifica en compilación que accedes a un dato con el mutex correcto cogido, si lo anotas.

Vale la pena ver la divergencia sobre un caso mínimo. Este fragmento tiene una fuga en una sola rama:

char *leer(int n) {
    char *buf = malloc(n);
    if (n > 1024)
        return nullptr;   /* buf se fuga solo por aqui */
    return buf;
}

Con -Wall -Wextra ninguno de los dos dice nada: la fuga no es un error de tipos, es una propiedad del flujo. Solo el análisis de rutas la ve, y cada compilador la presenta a su manera: GCC con -fanalyzer imprime la traza numerada de eventos que conducen a la fuga; Clang con scan-build genera un informe HTML navegable con la ruta resaltada sobre el código. Misma clase de bug, dos ergonomías distintas.

# el mismo fichero ante dos jueces distintos
gcc   -std=c23 -Wall -Wextra -fanalyzer prog.c -o prog_gcc
clang -std=c23 -Wall -Wextra -Wthread-safety prog.c -o prog_clang

# salida estructurada para consumir en CI
gcc -std=c23 -Wall -Wextra -fdiagnostics-format=json -c prog.c 2> avisos.json

Extensiones y soporte de C23

Ambos aceptan un núcleo común de extensiones históricas: expresiones-sentencia, __attribute__((cleanup)), __int128, typeof antes de que fuera estándar. Pero cada uno guarda cosas propias:

• Solo GCC: funciones anidadas, que se implementan con trampolines en la pila y chocan con las políticas de memoria no ejecutable.
• Solo Clang: los blocks (el operador ^), los calificadores de nulabilidad _Nullable y _Nonnull, y __attribute__((overloadable)).

Compilar con -Wpedantic en los dos es la forma barata de descubrir que dependes de una extensión sin saberlo.

En cuanto a C23, el terreno se ha estabilizado. GCC 14 y Clang 18 aceptan -std=c23; por debajo de esas versiones el nombre era provisional, -std=c2x. GCC 15 llegó incluso a cambiar su dialecto por defecto a gnu23, mientras Clang mantuvo gnu17 durante más tiempo: no asumas nunca el dialecto por defecto, decláralo siempre.

La forma honesta de saber dónde estás no es consultar una tabla, sino preguntárselo al compilador. C23 estandarizó __has_include y las macros de comprobación de características, así que la detección se escribe una vez y funciona en ambos:

#if __STDC_VERSION__ < 202311L
#  error "Este proyecto exige C23: compila con -std=c23"
#endif

#if defined(__has_embed)
#  define TENGO_EMBED 1
#endif

Comprobar __STDC_VERSION__ en una cabecera común es la disciplina que convierte un fallo confuso de sintaxis en un mensaje de error legible el primer día que alguien compila tu proyecto con un compilador viejo.

La estrategia: compilar con los dos

# la matriz mínima, cuatro combinaciones
for cc in gcc clang; do
  for opt in -O0 -O2; do
    "$cc" -std=c23 -Wall -Wextra -Werror "$opt" -g prog.c -o "prog_${cc}${opt}" || echo "FALLO $cc $opt"
  done
done