Changed between 20190512 and 20190519, rejects C variant : $ cat z0.c #pragma omp declare target #include <openacc.h> $ cat z1.cc #pragma omp declare target #include <openacc.h> $ gcc-10-20200126 -c z0.c -fopenmp -fopenacc z0.c:3: error: '#pragma omp declare target' without corresponding '#pragma omp end declare target' $ g++-10-20190512 -c z1.cc -fopenmp -fopenacc $ $ g++-10-20200126 -c z1.cc -fopenmp -fopenacc In file included from z1.cc:2: .../lib64/gcc/x86_64-pc-linux-gnu/10.0.1/include/openacc.h: In function 'int acc_on_device(acc_device_t)': .../lib64/gcc/x86_64-pc-linux-gnu/10.0.1/include/openacc.h:162:1: internal compiler error: Segmentation fault 162 | { | ^ 0xc3085f crash_signal ../../gcc/toplev.c:328 0xb17d41 oacc_verify_routine_clauses(tree_node*, tree_node**, unsigned int, char const*) ../../gcc/omp-general.c:1802 0x6e2732 cp_finalize_oacc_routine ../../gcc/cp/parser.c:42750 0x718bdc cp_parser_function_definition_from_specifiers_and_declarator ../../gcc/cp/parser.c:28734 0x718bdc cp_parser_init_declarator ../../gcc/cp/parser.c:20590 0x6fc6ee cp_parser_simple_declaration ../../gcc/cp/parser.c:13669 0x71f6d9 cp_parser_declaration ../../gcc/cp/parser.c:13368 0x6f786a cp_parser_oacc_routine ../../gcc/cp/parser.c:42669 0x6f786a cp_parser_pragma ../../gcc/cp/parser.c:43459 0x71fe51 cp_parser_translation_unit ../../gcc/cp/parser.c:4731 0x71fe51 c_parse_file() ../../gcc/cp/parser.c:43675 0x7e2560 c_common_parse_file() ../../gcc/c-family/c-opts.c:1186
Confirmed, started with r10-471-gb48f44bf77a39fef.
Reduced testcase: #pragma omp declare target #pragma acc routine seq void foo (void) {} #pragma omp end declare target This one ICEs in both C and C++.
From reading oacc_verify_routine_clauses, it seems that from OpenACC pragmas on a FUNCTION_DECL "omp declare target" attribute will have always non-NULL TREE_VALUE and (at least right now - for host/nohost we use separate attribute) from OpenMP pragmas will have NULL TREE_VALUE. So oacc_verify_routine_clauses either could complain about mixing OpenMP and OpenACC pragmas on the same decl, or could allow NULL TREE_VALUE and treat it as something (say seq).
Thomas, can I ping on this?
ACK, thanks for the report and initial analysis. Not sure if this is actually supposed to be valid or invalid code (but of course we shouldn't ICE either way). That GCC 9 accepts this doesn't mean too much, given that we don't know what it's supposed to mean. Until the interactions between OpenACC and OpenMP 'target' get defined properly, I suggest we make this a compile-time error. I'm testing a patch. (Not sure if a variant of that will be worth backporting to release branches, too?)
I have acked the patch in https://gcc.gnu.org/legacy-ml/gcc-patches/2020-03/msg00247.html, are you going to commit it?
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>: https://gcc.gnu.org/g:ff3f862b451496dd4afbe2dbfae82afab59a42c6 commit r10-7676-gff3f862b451496dd4afbe2dbfae82afab59a42c6 Author: Thomas Schwinge <thomas@codesourcery.com> Date: Wed Mar 4 17:58:33 2020 +0100 Handle 'omp declare target' attribute set for both OpenACC and OpenMP 'target' [PR89433, PR93465] ... which as of PR89433 commit b48f44bf77a39fefc238a16cf1225c6464c82406 causes an ICE. Not sure if this is actually supposed to be valid or invalid code. Until the interactions between OpenACC and OpenMP 'target' get defined properly, make this a compile-time error. gcc/ PR middle-end/89433 PR middle-end/93465 * omp-general.c (oacc_verify_routine_clauses): Diagnose if "#pragma omp declare target" has also been applied. gcc/testsuite/ PR middle-end/89433 PR middle-end/93465 * c-c++-common/goacc-gomp/pr93465-1.c: New file.
ICE fixed for GCC 10. Not planning to backport to release branches; mixed OpenACC/OpenMP code continues to invoke undefined behavior (without ICE).