https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121936
--- Comment #20 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> --- (In reply to Andrew Pinski from comment #18) > So NO cloning is not valid unless it is from a non vague call. > > You can see that with: [...] > Compile with -fno-inline and you will see: > check_arg_1_value(int, int) [clone .constprop.0]: > xorl %eax, %eax > ret What do you think is wrong here? What I'm seeing (https://godbolt.org/z/Gqbdfvbef) is a correct refinement of the original program -- this case seems to have been handled correctly by GCC. (The clone symbol isn't even referenced.) The problem would occur if, after optimization, we still have a reference to a vague linkage symbol (eg, a call to an inline function), but the user of that symbol has been optimized assuming a particular implementation of the function, using properties that are not true for all possible implementations. If you replace the reference to the vague linkage symbol with a reference to a local clone, then that problem cannot occur, because you know what the symbol will resolve to at runtime -- it will be the clone.
