[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #16 from CVS Commits --- The releases/gcc-10 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:60b589b5858fb8ad414583c6b493e0897f1bde5f commit r10-9681-g60b589b5858fb8ad414583c6b493e0897f1bde5f Author: Thomas Schwinge Date: Fri Apr 9 16:03:32 2021 +0200 Add 'libgomp.oacc-c-c++-common/static-variable-1.c' [PR84991, PR84992, PR90779] libgomp/ PR middle-end/84991 PR middle-end/84992 PR middle-end/90779 * testsuite/libgomp.oacc-c-c++-common/static-variable-1.c: New. (cherry picked from commit ffa0ae6eeef3ad15d3f288283e4c477193052f1a)
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #15 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:ffa0ae6eeef3ad15d3f288283e4c477193052f1a commit r11-8096-gffa0ae6eeef3ad15d3f288283e4c477193052f1a Author: Thomas Schwinge Date: Fri Apr 9 16:03:32 2021 +0200 Add 'libgomp.oacc-c-c++-common/static-variable-1.c' [PR84991, PR84992, PR90779] libgomp/ PR middle-end/84991 PR middle-end/84992 PR middle-end/90779 * testsuite/libgomp.oacc-c-c++-common/static-variable-1.c: New.
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #14 from Andrew Stubbs ---
(In reply to Jakub Jelinek from comment #7)
> if I compile just the first TU without the foo () call in there, and
> .global .align 4 .u32 var$lto_priv$1[1] = { 5 };
> .global .align 4 .u32 var$lto_priv$0[1] = { 5 };
> if I compile both, so there is some magic that makes these global and
> uglified so that there can be multiple such vars.
> No idea where that happens, whether it is NVPTX specific etc.
That ".global" doesn't refer to the object linkage; it refers to the "global"
memory region, as opposed to the "shared" or "local" memory.
In fact the compiler still regards the variable as "not public".
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #13 from Tom de Vries ---
(In reply to Tom de Vries from comment #11)
> (In reply to Thomas Schwinge from comment #1)
> > Same for OpenACC ('!$acc parallel copyout(v)').
> >
> >
> > Thsi sounds similar to PR85063,
> > > com> "[PATCH, PR85063] Fix switch conversion in offloading functions".
>
> There is a certain difference. There, switch conversion introduces a static
> var, while there is none in the source.
>
Oops, I just read in comment 0 "Fortran front-end is creating a local static
array", so you're right, this is similar.
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #12 from Tom de Vries --- *** Bug 84592 has been marked as a duplicate of this bug. ***
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #11 from Tom de Vries ---
(In reply to Thomas Schwinge from comment #1)
> Same for OpenACC ('!$acc parallel copyout(v)').
>
>
> Thsi sounds similar to PR85063,
> com> "[PATCH, PR85063] Fix switch conversion in offloading functions".
There is a certain difference. There, switch conversion introduces a static
var, while there is none in the source.
This is similar to the test-case in PR84592 comment 5 (where there is a static
var in the source). The patch from comment 10 makes that test-case pass.
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Sat Jun 15 07:09:04 2019 New Revision: 272322 URL: https://gcc.gnu.org/viewcvs?rev=272322=gcc=rev Log: PR middle-end/90779 * gimplify.c: Include omp-offload.h and context.h. (gimplify_bind_expr): Add "omp declare target" attributes to static block scope variables inside of target region or target functions. * c-c++-common/goacc/routine-5.c (func2): Don't expect error for static block scope variable in #pragma acc routine. * testsuite/libgomp.c/pr90779.c: New test. * testsuite/libgomp.fortran/pr90779.f90: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr90779.c trunk/libgomp/testsuite/libgomp.fortran/pr90779.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c trunk/libgomp/ChangeLog
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #9 from Jakub Jelinek --- Ok, will retest the updated version and commit, defer the rest to you or somebody else familiar with what is done there.
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #8 from Andrew Stubbs --- On GCN I get the lto_priv names, but not the globalization. I think that shows what the expected behaviour is, thanks ... I just need to find that magic. That being so, I think I can confirm that your original patch fixes the problem reported.
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
Jakub Jelinek changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org,
||vries at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
Something like:
extern int foo (void);
static int var = 5;
#pragma omp declare target to (var)
int
main ()
{
int r = 19;
#pragma omp target map(tofrom: r)
{
r += ++var;
}
#pragma omp target map(tofrom: r)
{
r += ++var;
}
if (r != 19 + 6 + 7)
__builtin_abort ();
foo ();
return 0;
}
in one source and:
static int var = 5;
#pragma omp declare target to (var)
int
foo ()
{
int r = 19;
#pragma omp target map(tofrom: r)
{
r += ++var;
}
#pragma omp target map(tofrom: r)
{
r += ++var;
}
if (r != 19 + 6 + 7)
__builtin_abort ();
return 0;
}
needs to work. Looking at the PTX assembly for this, I see
// BEGIN VAR DEF: var
.global .align 4 .u32 var[1] = { 5 };
//:FUNC_MAP "main$_omp_fn$1"
//:FUNC_MAP "main$_omp_fn$0"
//:VAR_MAP "var"
if I compile just the first TU without the foo () call in there, and
.global .align 4 .u32 var$lto_priv$1[1] = { 5 };
.global .align 4 .u32 var$lto_priv$0[1] = { 5 };
if I compile both, so there is some magic that makes these global and uglified
so that there can be multiple such vars.
No idea where that happens, whether it is NVPTX specific etc.
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #6 from Andrew Stubbs --- There's not observable difference. I don't quite follow what the patch is trying to achieve, but seems like adding the variable to the offload variables does not address the issue here. I've added a hack to mkoffload to force the variables listed in the offload_var_table to be declared "global". This is sufficient to run the small testcase correctly. (My larger testcase now has a memory fault, but that could easily be unrelated.) If the symbol is declared local then there's no (straight-forward) way to locate the loaded symbol at runtime, hence the libgomp plugin fail. Setting the symbol global seems like there could be other issues. Given that libgomp does not actually need access to this variable at runtime, perhaps the plugin should just ignore the failure and move on, trusting that unfound variables are not needed?
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
--- Comment #5 from Jakub Jelinek ---
(In reply to Andrew Stubbs from comment #4)
> The problem is that the variables are added to the offload_var_table but not
> exported so that libgomp cannot find the symbol at load time. This causes a
> fatal error in a mutex-locked section, which causes libgomp's atexit handler
> to hang trying to take the same lock.
They should be in offload_var_table and should not be exported, it is like any
static filescope variable marked for offload.
Completely wild guess, does incremental:
@@ -65,6 +65,8 @@
#include "attribs.h"
#include "asan.h"
#include "dbgcnt.h"
+#include "omp-offload.h"
+#include "context.h"
/* Hash set of poisoned variables in a bind expr. */
static hash_set *asan_poisoned_variables = NULL;
@@ -1350,7 +1352,15 @@
= tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (t));
varpool_node *node = varpool_node::get (t);
if (node)
- node->offloadable = 1;
+ {
+ node->offloadable = 1;
+ if (ENABLE_OFFLOADING && !DECL_EXTERNAL (t))
+ {
+ g->have_offload = true;
+ if (!in_lto_p)
+ vec_safe_push (offload_vars, t);
+ }
+ }
}
break;
}
patch help?
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #4 from Andrew Stubbs --- The problem is that the variables are added to the offload_var_table but not exported so that libgomp cannot find the symbol at load time. This causes a fatal error in a mutex-locked section, which causes libgomp's atexit handler to hang trying to take the same lock. The question is then, are the variables supposed to be in the offload_var_table? If so, why? Aren't these just preinitialized constants?
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #3 from Andrew Stubbs --- My code now compiles successfully, with the patch, but it hangs at runtime. I need to investigate, but debugging runtime issues on the GPU is slow work.
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #2 from Jakub Jelinek --- Created attachment 46484 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46484=edit gcc10-pr90779.patch Fix, so far tested with x86_64-linux -> nvptx-none offloading make check in libgomp, will do full bootstrap/regtest later on. I've discussed it in the OpenMP language committee and the desire is to clarify it the way the patch implements it, block scope statics in omp declare target to routines should have the same declare target status as the containing functions and similarly in target regions it should be omp declare target to.
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779
Thomas Schwinge changed:
What|Removed |Added
Keywords||openacc
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-06-07
CC||jakub at gcc dot gnu.org,
||tschwinge at gcc dot gnu.org
Summary|Fortran array |Fortran array
|initialization in OpenMP|initialization in offload
|offload regions |regions
Ever confirmed|0 |1
--- Comment #1 from Thomas Schwinge ---
Same for OpenACC ('!$acc parallel copyout(v)').
Thsi sounds similar to PR85063,
"[PATCH, PR85063] Fix switch conversion in offloading functions".
