------- Comment #11 from scovich at gmail dot com 2009-05-13 09:51 ------- > If you allow inline asms to change control flow, even just > to labels whose address has been taken through &&label, you > penalize a lot of code which doesn't change the control > flow, as the compiler will have to assume each inline asm > which could possibly get at an label address (not just > directly, but through global variables, pointers etc.) can > jump to it.
I'm going to invoke #3 again to respond to these concerns: a. This RFE is specifically limited to local control flow only, so the compiler can safely ignore any label not in the asm's enclosing function, as well as labels whose addresses are never taken (or provably never used). Computed gotos appear to make the same assumptions, based on the docs' strong warning not allow labels to leak out of their enclosing function in any way. b. While it's always possible that an asm could jump to a value loaded from an arbitrary, dynamically-generated address, the same is true for computed gotos. Either way, compiler analysis or not, doing so would almost certainly send you to la-la land because label values aren't known until assembler time or later and have no guaranteed relationship with each other. The only way to get a valid label address is using one directly, or computing it with some sort of base+(label-base). Either way requires taking the address of the desired label at some point and tipping off the compiler. c. It's pretty easy to write functions whose computed gotos defy static analysis, but most of the time the compiler does pretty well. Well-written asm blocks should access memory via "m" constraints -- which the compiler can analyze -- rather than manually dereferencing a pointer passed in with an "r" constraint. This is especially true for asm blocks with no internal control flow, which this RFE encourages. d. If a code path is short/simple enough that incoming jumps penalize it heavily (whether from computed gotos or jumps from asm), it's probably also small enough that the compiler (or programmer, if need be) can duplicate it for the short path. A big, ugly code path probably wouldn't even notice an extra control flow arc or two. In the end, a big goal of this RFE is to allow programmers to make the compiler aware of control flow arcs they're already adding (or tempted to add) behind its back. It therefore wouldn't strike me as much of a limitation if "jumps to labels not explicitly passed to the asm are unsupported and may lead to undefined behavior." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
