This is the great example that @mysterymath came up with to explain the problem in the bug reported to gcc (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106725)

==> ext.c <==
void set_value(int v);

void external_call(void) {
  set_value(0);
}

==> lto.c <==
static int value;
void set_value(int v) { value = v; }
int get_value(void) { return value; }

==> main.c <==
#include <stdio.h>

void set_value(int v);
int get_value(void);
__attribute__((leaf)) void external_call(void);

int main(void) {
  set_value(42);
  external_call();
  printf("%d\n", get_value());
}

This is the scenario that I was trying to summarize here, where a function with nocallback attribute returns to its caller's module other than a return or an exception. external_call() is the function that has the leaf attribute, and main() is its caller. Normally, external_call() returns to its caller's module via a return. When lto.c and main.c are linked together, external_call() calls an imported function(set_value()), which is now in the same module with its caller. So, it returned to its caller's module via a function call, not with a return or an exception.

When all three modules are LTO-linked, leaf attribute is not going to have any effect based on the GCC description ("The attribute has no effect on functions defined within the current compilation unit").
https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html

You are right that we are being overly conservative about the usage of leaf attribute, and we plan to drop it for any LTO-ed code. The issue is that there was a lot of disagreement on the semantics of the leaf attribute for LTO usage (https://reviews.llvm.org/D131628), and we were not able to get a clear answer from the GCC community. Therefore, we decided to go with the restricted semantics.

Thanks for the clarification. Can you add the note about it having no effect on functions defined within the unit to the description in D131628?

Revisiting the example you included, I would suggest something like the following wording (keep your original 2 sentences but modify the example description):

For example, the nocallback function may contain a call to another module. But if we merge its caller and callee module here, and not the module containing the nocallback function definition itself, the nocallback property will be violated (since the nocallback function will call back into the newly merged module containing both its caller and callee). This could happen if the module containing the nocallback function definition is native code, so it does not participate in the LTO link. Note if the nocallback function does participate in the LTO link, and thus ends up in the merged module containing its caller and callee, removing the attribute doesn't hurt as it has no effect on definitions in the same compilation unit.

I incorporated your comment in the latest revision, and extended the description in D131628.