← board

Reduction

char *f(char *d){ *d = 0; return d; }     /* xtensa: IR_UNSUPPORTED kind 5 */
char  g(char *d){ return *d; }            /* xtensa: ok */
shape xtensa riscv32
*d = 0 (char store through a param) IR_UNSUPPORTED kind 5 ok
*d = 65 (non-zero) IR_UNSUPPORTED kind 5 ok
d++; *d = 0 IR_UNSUPPORTED kind 5 ok
void f(char *d){ *d = 0; } (result unused) IR_UNSUPPORTED kind 5 ok
int *f(int *d){ *d = 0; ... } IR_UNSUPPORTED kind 5 ok
return *d (read, same parameter) ok ok

So: the STORE, any width, whether or not the value or the pointer is used afterwards. Not the dereference, not the constant, not char.

AN_BINOP = 5 (defs.inc:745) is the C frontend's assignment-expression node. The lowering that handles it is reached on riscv32 and not on xtensa, which says the store path branches on target somewhere it should not — the two ESP backends are otherwise the pair that share this shape.

What it costs today

lib/crtl/src/string.c:188 is *d = '\0' in strncat. Compiling that file alone for xtensa refuses at 188, so every xtensa C program that pulls crtl in refuses at the same line — measured with strlen, puts and printf, each of which resolves to a crtl implementation. A program that calls only its own functions, or declares an external pxx does not implement, compiles.

The line number is the imported unit's and carries no file name, which is the usual trap: three unrelated programs all report pascal26:188 and it reads as one shared cause in the SUBJECT. It is one shared cause, in string.c.

Why it has stayed invisible

--target=xtensa refuses a C executable outright (C program entry stub on xtensa: a STANDALONE ...), so --emit-obj is the only C route on xtensa, and nothing in the tier drives an xtensa C object that calls libc. The ESP rows in test-emit-obj build Pascal.

Whether the Pascal frontend has the same gap is NOT measured here. The reduction and the whole table above are C. Someone should check before assuming this is C-only.

Found by

Writing an xtensa probe for [[feature-a-a-target-generic-resolve-and-compare-harness-for-emit-obj-objects]]. The harness printed SKIP -- pxx cannot emit an object here with the compiler's own diagnostic rather than passing over the target, which is the only reason it was seen. Filed rather than routed past, so the next person to write an xtensa probe does not rediscover it.

Umbrella

[[meta-a-pxx-produces-linkable-code]]