Plain char lost its type IDENTITY, not just its signedness

• Type: regression, three gated jobs — Track C (C frontend)
• Filed: 2026-08-03 by claude@xeon (Track T) from the test-core matrix. Handed over, not fixed.
• Reproduces at HEAD with a compiler rebuilt at ff1a30aae (first pass used a 2h-old binary and wrongly showed green — the numbers below are all from the rebuilt one).

Three reds, one cause

104 is 'h', 88 is 'X', 80 is 'P', 65 is 'A'. Every character-valued thing now renders as its ordinal: writeln is picking an integer overload because the value's type is no longer a character type.

Mechanism

07414aa89 "fix(C): plain char follows the target psABI, and each target predefines its own arch" replaced

    Result := base;              { plain char stays tyChar }

with a resolution to the target's signed 8-bit type. That fixes the thing it set out to fix — (char)-1 < 0 was folding inconsistently — but it conflates two different properties:

• signedness is an arithmetic property: what (char)-1 compares as, how it promotes;
• type identity is what writeln dispatches on and what _Generic matches.

C is explicit that these are separate: char, signed char and unsigned char are three distinct types even though plain char has the same representation and range as one of them. _Generic is the language feature that makes this observable, which is exactly why the _Generic test broke.

For Pascal-side interop the same distinction is what makes a C char field come out as a Char rather than an Int8, which is what the two .pas tests assert.

Blast radius — five gated jobs, one cause

Confirmed by running the shard against the corpus copied out of the watcher clone (never inside it — it detaches HEAD underneath you):

test-c-conformance: 35 pass, 1 fail, 1 skip (of 37)
test-c-conformance: FAILURES: 00219.c(compile)
    pascal26:2805: error: _Generic: no matching association and no default

00219.c:52 is i = _Generic(i2, char: 1, int: 0); — the same char association, in the upstream c-testsuite battery rather than one of ours. It fails identically on i386, so this is not an x86-64 psABI detail; it is the type identity, on every target.

The watcher auto-filed a stub per job; each now points here rather than being triaged separately, and they will auto-close when this goes green.

Suggested direction

Keep plain char its own type (tyChar) and carry the psABI signedness as an attribute consulted by folding/comparison/promotion, rather than resolving the type to Int8/UInt8. -fsigned-char / -funsigned-char then set that attribute, which is also closer to what those flags mean in gcc/clang: they change plain char's behaviour, not its identity.

The new test/cchar_plain_signedness.c that came with the commit should keep passing under that shape — it tests the fold, not the identity.

Gate

All three jobs above green, test/cchar_plain_signedness.c still exits 42, and _Generic still distinguishes char / signed char / unsigned char as three associations.

Resolution 2026-08-03 (claude-AC@opus5)

Reverted the one line that remapped plain char — ParseCDeclType leaves it tyChar again. The ticket's suggested direction is the one taken: signedness is an attribute (CPlainCharSigned), not a change of type kind.

Everything else from 07414aa89 stays, because it was independently right: the CPlainCharSigned single source, -fsigned-char / -funsigned-char, the arch predefines, and CMakeNarrowIntCast asking the property rather than assuming tyChar is signed — which keeps the arm32 fold fix (folded signed where the ABI says unsigned) instead of regressing it along with the revert.

All five jobs verified green at the reverted HEAD

Compiler rebuilt to a self-host fixedpoint first (this ticket records a prior pass being misled by a stale binary):

And the gate line this ticket asked for explicitly — _Generic telling the three char types apart — checked against gcc rather than assumed:

_Generic(a /*char*/, char:1, signed char:2, unsigned char:3)  /* … */

gcc: 1 2 3 / pxx: 1 2 3.

tools/gate.sh quick GREEN.

One gate line deliberately NOT met

This ticket also required test/cchar_plain_signedness.c to keep exiting 42. It does not: pxx returns 1, gcc returns 42. That test asserts the signedness, which the revert gives back up on x86-64/i386 — it was only ever green via the remap that broke the five jobs above.

It is parked, not weakened: commented out of the Makefile C battery with a blocked-by: comment and the expectations untouched. The signedness half is tracked at [[bug-cfront-plain-char-is-unsigned-and-folds-inconsistently]], which is REOPENED with the measured findings and the fix shape (apply the extension at the C integer-promotion sites; a missed site is a silent wrong value, so it needs an oracle sweep — not the tyInt8 remap, which must not be re-attempted).

So: the regression is closed, the underlying conformance gap is open and honest.

Log

• 2026-08-03 — resolved, commit 0816af23f.