[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