[Bug fortran/65419] New: incorrect sibcalls to libgomp functions
cesar at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Fri Mar 13 17:52:00 GMT 2015
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
More information about the Gcc-bugs
mailing list