https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122835
--- Comment #9 from Linus Torvalds <[email protected]> --- (In reply to Jakub Jelinek from comment #8) > Regarding asm goto, I don't see that documented anywhere, anyway, gcc has > behaved that way forever. > Anyway, unlike computed goto/longjmp, I think asm goto is at least in theory > changeable, the question is if we do want that. So we fixed this for this in the kernel, where we just make the "asm goto" go to a local label, and then that local label does a real goto. Then we just depend on the compiler doing the obvious branch following. And obviously gcc could just do exactly that internally, and it presumably wouldn't be very complicated. Anyway, the behavior itself is not a huge deal, and this was never a big problem for us, but the one thing I _would_ ask for is a warning if at all possible. Because while it's easy to fix once you realize, it can be *very* hard to notice, particularly if you have code that uses asm goto, works fine, and then you add some new cleanup logic, and the "asm goto" now subtly doesn't do the cleanup. That's particularly true for the kernel, since the most common case of "asm goto" use is literally for exceptional circumstances (ie the typical case is EFAULT handling for user space accesses that fail). So a warning when there's an asm goto with the target being out of scope that has a cleanup would be very appreciated...
