https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
Bug ID: 65419 Summary: incorrect sibcalls to libgomp functions Product: gcc Version: unknown Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at gcc dot gnu.org CC: jakub at gcc dot gnu.org I'm not sure if this problem is fortran specific, but I noticed that gfortran is identifying calls to libgomp, specifically GOACC_data_end, as a sibcall if a acc data region is the last statement inside the main function. That's a problem because GOACC_data_end transfers data from the accelerator to the host at the end of an acc data region. In the attached test case, the data in question happens to be allocated on the stack. If you look at the epilogue of the stack frame call GOACC_data_start movq %rbx, %rsi movq %rsp, %rdi call __field_summary_kernel_module_MOD_field_summary_kernel addq $1296, %rsp .cfi_def_cfa_offset 16 popq %rbx .cfi_def_cfa_offset 8 # SUCC: EXIT [100.0%] (ABNORMAL,SIBCALL) jmp GOACC_data_end .cfi_endproc .LFE1: you'll see that %rsp is restored before GOACC_data_end is called. You should be able to reproduce this bug with "-fopenacc -O2". Did we specify the built-in declaration for GOACC_data_end wrong, or is this a fortran specific quirk? I don't mind fixing it, but I'm not even sure what a sibling call is. I think it has something to do with recursion. Cesar