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]]