https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> --- Is there a reason we don't use an undefined instruction that will trap? 0xfffd is mentioned as permanently undefined here on page 85: http://documentation.renesas.com/doc/products/mpumcu/rej09b0003_sh4a.pdf I actually had trouble getting Linux to trap this; it's one thing I need to investigate on the kernel side, which is why I didn't reply earlier. I'll report my findings later. One other thing I'm wondering about is the contract for clobbers on the function call version. Is __builtin_trap supposed to be able to return? I was under the impression that it's noreturn, in which case there would be no requirements on what it can clobber, but there may be calling-convention issues still: Is it callable via PLT? On FDPIC targets, does the function receive a valid GOT pointer in r12 so that it can make further calls/data access? Also, if the expectation is that the trap will not return, does the trapa need the bug workaround? Does the bug (requiring the 5x or) take place at the time the trapa is executed, or at the time of return to the instruction after it? This is not well-documented and I remember looking into it before but I don't remember the answer.
