https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92827
Bug ID: 92827
Summary: Missing data/state sharing/propagation between host
and offloading devices
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: openacc, openmp
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
Target Milestone: ---
An issue known for a long time, now finally put into a PR.
We're currently missing data/state sharing/propagation between host and
offloading devices, which can lead to inconsistencies in behavior, and other
surprises. In particular, this concerns the state kept by all involved runtime
libraries, such as libgomp itself, libgfortran, libc/libm.
At process creation time, no constructors etc. are executed for offload devices
to initialize the respective runtime libraries' state, so these run with
uninitialized state, and we're lucky that this is doing reasonable things most
of the time.
---
For example,
<http://mid.mail-archive.com/875zvynbml.fsf@euler.schwinge.homeip.net>:
On 2018-12-12T14:00:18+0100, Thomas Schwinge <tho...@codesourcery.com> wrote:
> On Wed, 12 Dec 2018 10:36:17 +0100, Jakub Jelinek <ja...@redhat.com> wrote:
>> Eventually we need to find a way how to transfer some ICVs and other data
>> from the host to the offloading library, either process shared that aren't
>> changing, which can include the hostname, getpid, or some others that would
>> need to be passed for every target region.
>
> That would probably also include any state that the respective language
> runtime libraries maintain? For example, C's global rounding mode as set
> my "fesetround". ..., and I now wonder how to propagate that from the
> host libc to the target libcs, for example host: glibc vs. nvptx
> offloading: newlib -- have to do a host-side "fegetround" before each
> offloaded code region, or at least when there's been an intermediate
> host-side "fesetround" call (so have to track these?), and likewise for
> any other such state-changing functions? Also, the "options" array and
> call of "_gfortran_set_options" that the Fortran front end synthesizes
> into each "main" function?
Or,
<http://mid.mail-archive.com/2d74db4f-afc0-2821-51ce-88e64033c98a@codesourcery.com>:
On 2019-12-05T09:44:26+0100, Tobias Burnus <tob...@codesourcery.com> wrote:
> +! In gfortran's main program, libfortran's set_options is called - which sets
> +! compiler_options.backtrace = 1 by default. For an offload libgfortran,
> this
> +! is never called and, hence, "Error termination." is never printed. Thus:
> +! { dg-output "Error termination.*" { target { ! {
> openacc_nvidia_accel_selected || openacc_amdgcn_accel_selected } } } }
---
Probably the first task is to run any such constructors/setup on the offload
devices at all, and another task then is to keep state synchronized between
host and offload devices.
