This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/65419] incorrect sibcalls to libgomp functions
- From: "cesar at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 18 Mar 2015 13:44:57 +0000
- Subject: [Bug fortran/65419] incorrect sibcalls to libgomp functions
- Auto-submitted: auto-generated
- References: <bug-65419-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65419
--- Comment #2 from cesar at gcc dot gnu.org ---
Created attachment 35058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35058&action=edit
__builtin_GOACC_data_end
Sorry, I thought I included this test case. Anyway, the !$acc data regions is
associated with two libgomp calls, __builtin_GOACC_data_start and
__builtin_GOACC_data_end. Basically, as the control enters an acc data region,
all of the variables specified inside a data clause get transferred over to the
accelerator. At the end of the data region, GOACC_data_end transfers the data
back to the host as necessary. No arguments are passed to GOACC_data_end.
Instead the runtime maintains a stack of data regions because they are
permitted to nest, and GOACC_data_end decreases the reference count on all of
the variables pushed on that stack and transfers the data back to the host as
necessary.
Did we specify the builtin function for GOACC_data_end wrong, or is there an
inherent weakness in the sibling call analysis?