http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-12-20 22:34:43 UTC --- On Tue, 20 Dec 2011, sipych at gmail dot com wrote: > "On platforms that do not support dynamic pre-emption of symbols an unresolved > weak reference to a symbol relocated by R_ARM_CALL shall be treated as a jump > to the next instruction (the call becomes a no-op). The behaviour of > R_ARM_JUMP24 in these conditions is unspecified." > > At least, tail call + epilogue shall not be replaced by (undefined) JUMP. That's an ABI specifying relocation handling, not an API specifying semantics of C source code. The C semantics are as specified in the C standard, i.e. undefined behavior if the call is executed; C is a high-level language not a portable assembler and the semantics are those of the C standard not those of particular instructions you might guess have some relation to particular C operations. The EABI semantics say what happens with a relocation that might have been generated from code where the call is properly conditional in the C source, or might have been generated from code with undefined behavior. It would be valid for the compiler to rely on the EABI semantics to optimize code generation for "if (wfunc) wfunc ();", for example, but those semantics do not change the undefined nature of code that doesn't condition the call.
