/* -O2 -mcpu=power8 */ static int __attribute__ ((target("cpu=power10"),noclone,noinline)) local_func (int x) { return x; } int main() { return local_func (0); } results in a linker complaint "call to `local_func' lacks nop, can't restore toc; (toc save/adjust stub)". rs6000.md call_local et al patterns can't be allowed to match when caller/callee disagree about r2 usage.
We will want this backported to GCC 10 too, correct?
Yes, it is a bug present in any gcc version supporting pcrel.
The master branch has been updated by Alan Modra <amodra@gcc.gnu.org>: https://gcc.gnu.org/g:f8ac30f1653ff69706c35af6d725f1d330600f11 commit r11-2603-gf8ac30f1653ff69706c35af6d725f1d330600f11 Author: Alan Modra <amodra@gmail.com> Date: Thu Aug 6 14:12:21 2020 +0930 PR96493, powerpc local call linkage failure This corrects current_file_function_operand, an operand predicate used to determine whether a symbol_ref is safe to use with the local_call patterns. Calls between pcrel and non-pcrel code need to go via linker stubs. In the case of non-pcrel code to pcrel the stub saves r2 but there needs to be a nop after the branch for the r2 restore. So the local_call patterns can't be used there. For pcrel code to non-pcrel the local_call patterns could still be used, but I thought it better to not use them since the call isn't direct. Code generated by the corresponding call_nonlocal_aix for pcrel is identical anyway. Incidentally, without the TREE_CODE () == FUNCTION_DECL test, gcc.c-torture/compile/pr37433.c and pr37433-1.c ICE. Also, if you make the test more strict by disallowing an op without a SYMBOL_REF_DECL then a bunch of go and split-stack tests fail. That's because a prologue call to __morestack can't have a following nop. (__morestack calls its caller at a fixed offset from the __morestack call!) gcc/ PR target/96493 * config/rs6000/predicates.md (current_file_function_operand): Don't accept functions that differ in r2 usage. gcc/testsuite/ * gcc.target/powerpc/pr96493.c: New file.
(In reply to Alan Modra from comment #2) > Yes, it is a bug present in any gcc version supporting pcrel. Ok, then I'm setting the target milestone to GCC 10.3.
I think this has baked on trunk enough now. Can we get this backported to GCC 10 along with the updated test case fix from PR96525? I'd like to merge this along with some other backports I have done into the IBM GCC 10 branch.
The releases/gcc-10 branch has been updated by Alan Modra <amodra@gcc.gnu.org>: https://gcc.gnu.org/g:61e46440e8124ba605f7ff81aaf1a19176d0c14b commit r10-8615-g61e46440e8124ba605f7ff81aaf1a19176d0c14b Author: Alan Modra <amodra@gmail.com> Date: Thu Aug 6 14:12:21 2020 +0930 PR96493, powerpc local call linkage failure This corrects current_file_function_operand, an operand predicate used to determine whether a symbol_ref is safe to use with the local_call patterns. Calls between pcrel and non-pcrel code need to go via linker stubs. In the case of non-pcrel code to pcrel the stub saves r2 but there needs to be a nop after the branch for the r2 restore. So the local_call patterns can't be used there. For pcrel code to non-pcrel the local_call patterns could still be used, but I thought it better to not use them since the call isn't direct. Code generated by the corresponding call_nonlocal_aix for pcrel is identical anyway. Incidentally, without the TREE_CODE () == FUNCTION_DECL test, gcc.c-torture/compile/pr37433.c and pr37433-1.c ICE. Also, if you make the test more strict by disallowing an op without a SYMBOL_REF_DECL then a bunch of go and split-stack tests fail. That's because a prologue call to __morestack can't have a following nop. (__morestack calls its caller at a fixed offset from the __morestack call!) gcc/ PR target/96493 * config/rs6000/predicates.md (current_file_function_operand): Don't accept functions that differ in r2 usage. gcc/testsuite/ * gcc.target/powerpc/pr96493.c: New file. (cherry picked from commit f8ac30f1653ff69706c35af6d725f1d330600f11)
Patches applied to master and gcc-10