When compiling this openacc testcase: .... #include <stdio.h> int main (void) { int n[1]; n[0] = 3; #pragma acc parallel copy(n) { static const int test[] = {1,2,3,4}; n[0] = test[n[0]]; } printf ("n: %d\n", n[0]); return 0; } ... we run into an ICE: ... lto1: internal compiler error: in input_varpool_node, at lto-cgraph.c:1424^M ... We've reported the ICE at PR84592, where we use a slightly more complicated example. But the first question here is: is this a valid openacc program? Given that function static variables are not supported in functions to which a routine directive applies, are function static variables supported in parallel regions, or not? If not, we should emit a proper error message. If so, we should implement the required semantics.
(In reply to Tom de Vries from comment #0) > > But the first question here is: is this a valid openacc program? > > Given that function static variables are not supported in functions to which > a routine directive applies, are function static variables supported in > parallel regions, or not? > > If not, we should emit a proper error message. > > If so, we should implement the required semantics. With the PGI compiler, we can compile and run the program.
(In reply to Tom de Vries from comment #0) > When compiling this openacc testcase: > .... > #include <stdio.h> > > int > main (void) > { > int n[1]; > n[0] = 3; > #pragma acc parallel copy(n) > { > static const int test[] = {1,2,3,4}; > n[0] = test[n[0]]; > } > printf ("n: %d\n", n[0]); > > return 0; > } > ... > > we run into an ICE: > ... > lto1: internal compiler error: in input_varpool_node, at lto-cgraph.c:1424^M > ... > > We've reported the ICE at PR84592, where we use a slightly more complicated > example. > > But the first question here is: is this a valid openacc program? > > Given that function static variables are not supported in functions to which > a routine directive applies, are function static variables supported in > parallel regions, or not? > > If not, we should emit a proper error message. > > If so, we should implement the required semantics. Thomas, can you get this clarified with the OpenACC standard people? Thanks, - Tom
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>: https://gcc.gnu.org/g:ffa0ae6eeef3ad15d3f288283e4c477193052f1a commit r11-8096-gffa0ae6eeef3ad15d3f288283e4c477193052f1a Author: Thomas Schwinge <thomas@codesourcery.com> 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.
The releases/gcc-10 branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>: https://gcc.gnu.org/g:60b589b5858fb8ad414583c6b493e0897f1bde5f commit r10-9681-g60b589b5858fb8ad414583c6b493e0897f1bde5f Author: Thomas Schwinge <thomas@codesourcery.com> 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)
(In reply to Tom de Vries from comment #2) > (In reply to Tom de Vries from comment #0) > > When compiling this openacc testcase: > > [...] ... this now works as expected. Current behavior documented via commit ffa0ae6eeef3ad15d3f288283e4c477193052f1a "Add 'libgomp.oacc-c-c++-common/static-variable-1.c' [PR84991, PR84992, PR90779]". > get this clarified with the OpenACC standard people? See <http://mid.mail-archive.com/87r1jjxxk7.fsf@euler.schwinge.homeip.net>; waiting for OpenACC specification, thus setting "suspended" here.