Looking at the generated instructions might give a clue, but I'm just as mystified. Given the size of the program, I doubt there's much of it to inspect anyway.

Maybe it's a hardware trap and not a regular null reference segmentation fault?

Well, shl doesn't trap on x86 for out of range values; it just masks the second operand by 0x1f [1]. But it could be some other kind of trap.

Complete guess in the dark: tcc misencoded an instruction causing an illegal instruction trap, maybe in some sort of misguided attempt to optimize the shift to a lea.

[1]: http://x86.renejeschke.de/html/file_module_x86_id_285.html

Wouldn't that normally produce SIGILL, not SIGSEGV?