Using gcc 4.2 from SVN: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/local_scratch/owe043/gcc_svn Thread model: posix gcc version 4.2.0 20060523 (experimental) I get an ICE when when compiling (g++ -fopenmp omp.cc) the following program: #define parallel_for _Pragma("omp parallel for") for #define parallel _Pragma("omp parallel") int main() { parallel { } parallel_for (int i = 0; i < 1000; ++i) { } return 0; }
Created attachment 11502 [details] c++ file which causes ICE
The ICE: t1.cc:9: internal compiler error: Abort trap Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. The backtrace: #0 0x90128b54 in abort () #1 0x00b6a898 in _cpp_backup_tokens (pfile=0x43805200, count=2) at ../../libcpp/macro.c:1206 #2 0x00b62ce4 in do_pragma (pfile=0x43805200) at ../../libcpp/directives.c:1321 #3 0x00b640fc in destringize_and_run (pfile=0x43805200, in=0x2) at ../../libcpp/directives.c:1508 #4 0x00b6ab38 in builtin_macro (pfile=0x43805200, node=0x434e6290) at ../../libcpp/macro.c:295 #5 0x00b6b990 in cpp_get_token (pfile=0x43805200) at ../../libcpp/macro.c:784 #6 0x00296038 in c_lex_with_flags (value=0xd410bc, loc=0xd410c0, cpp_flags=0xd410b6 "?????????????B") at ../../gcc/c-lex.c:340 #7 0x00137034 in cp_lexer_get_preprocessor_token (lexer=0x434e86c0, token=0xd410b4) at ../../gcc/cp/parser.c:394 #8 0x00136cd4 in cp_lexer_new_main () at ../../gcc/cp/parser.c:295 #9 0x0013a630 in cp_parser_new () at ../../gcc/cp/parser.c:2478 #10 0x0015d444 in c_parse_file () at ../../gcc/cp/parser.c:19140 #11 0x002a79c0 in c_common_parse_file (set_yydebug=0) at ../../gcc/c-opts.c:1164 #12 0x00540260 in compile_file () at ../../gcc/toplev.c:999 #13 0x00542b3c in do_compile () at ../../gcc/toplev.c:1970
C also has the same issue.
Here is a reduced testcase: #define parallel _Pragma("omp parallel") int main() { #pragma omp parallel {} } ---- The question is does macros allow to stuff in #pragmas. I want to say yes. Anyways here is a non openmp testcase that fails currently but it ICEs differently: #define push _Pragma ("pack(push)") #define push1 _Pragma ("pack(push)") push1
(In reply to comment #4) > Anyways here is a non openmp testcase that fails currently but it ICEs > differently: And I am going to file a different bug about that.
(In reply to comment #4) > The question is does macros allow to stuff in #pragmas. > I want to say yes. I changed my mind, no it should not be except for some cases. Or at least the documented ones. I don't even think this change in the behavior of Pragmas are documented.
I should note this is accepted with -save-temps so the preprocessor is doing the correct thing at least to a point. I bet PR 27747 and 27748 are really all the same issue.
I found out about _Pragma from the following page (at the bottom): http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Function-Attributes.html While it is not essential behaviour to allow _Pragma's to be generated from macros, there are cases where it would be very useful. In my case I would really like to be able to control the OpenMP directives that get included at a fine grained level without littering my code with #ifdef's.
(In reply to comment #8) > I found out about _Pragma from the following page (at the bottom): You can work around this bug by using the -save-temps option. Even though _Pragma is an extension to C++ and C89/90, it is a standard feature in C99 and I can report that it ICEs in C99 mode also.
#define parallel _Pragma("omp parallel") int main() { #pragma omp parallel {} } is ICE on invalid code, OpenMP 2.5 says in 2.1 Directive Format: Preprocessing tokens following the #pragma omp are subject to macro replacement. And, #pragma omp _Pragma ("omp parallel") is of course not valid.
So far fixed the valid cases of _Pragma with -fopenmp I came up, still need to work some more on the invalid ones.
(In reply to comment #10) > #define parallel _Pragma("omp parallel") > int > main() > { > #pragma omp parallel > {} > } This is not invalid according to: http://gcc.gnu.org/onlinedocs/cpp/Implementation_002ddefined-behavior.html Which says the following (unless that is not up to date also): Treatment of a `#pragma' directive that after macro-expansion results in a standard pragma. No macro expansion occurs on any `#pragma' directive line, so the question does not arise. Note that GCC does not yet implement any of the standard pragmas.
Subject: Bug 27746 Author: jakub Date: Fri Jun 9 21:13:25 2006 New Revision: 114519 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114519 Log: PR preprocessor/27746 * directives.c (do_pragma): Handle pragma with valid namespace and invalid name coming from macro expansion. * directives.c (destringize_and_run): Initialize next field in context. PR c/27747 PR c++/27748 * directives.c (destringize_and_run): Set NO_EXPAND on the tokens. * macro.c (_cpp_backup_tokens): Fix comment typo. testsuite/ PR c/27747 * gcc.dg/cpp/_Pragma6.c: New test. PR c++/27748 * g++.dg/cpp/_Pragma1.C: New test. PR preprocessor/27746 * gcc.dg/gomp/macro-3.c: New test. * gcc.dg/gomp/macro-4.c: New test. * g++.dg/gomp/macro-3.C: New test. * g++.dg/gomp/macro-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp/_Pragma1.C trunk/gcc/testsuite/g++.dg/gomp/macro-3.C trunk/gcc/testsuite/g++.dg/gomp/macro-4.C trunk/gcc/testsuite/gcc.dg/cpp/_Pragma6.c trunk/gcc/testsuite/gcc.dg/gomp/macro-3.c trunk/gcc/testsuite/gcc.dg/gomp/macro-4.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/macro.c
Should be fixed in SVN.