[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Andrew Pinski changed: What|Removed |Added CC||liavonlida at gmail dot com --- Comment #35 from Andrew Pinski --- *** Bug 113587 has been marked as a duplicate of this bug. ***
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Andrew Pinski changed: What|Removed |Added CC||domen.stangar at gmail dot com --- Comment #34 from Andrew Pinski --- *** Bug 111758 has been marked as a duplicate of this bug. ***
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Richard Biener changed: What|Removed |Added Target Milestone|10.5|---
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Jakub Jelinek changed: What|Removed |Added Target Milestone|10.4|10.5 --- Comment #33 from Jakub Jelinek --- GCC 10.4 is being released, retargeting bugs to GCC 10.5.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #32 from Martin Sebor --- *** Bug 101538 has been marked as a duplicate of this bug. ***
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Richard Biener changed: What|Removed |Added Target Milestone|10.3|10.4 --- Comment #31 from Richard Biener --- GCC 10.3 is being released, retargeting bugs to GCC 10.4.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Richard Biener changed: What|Removed |Added Target Milestone|10.2|10.3 --- Comment #30 from Richard Biener --- GCC 10.2 is released, adjusting target milestone.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Jakub Jelinek changed: What|Removed |Added Target Milestone|10.0|10.2 --- Comment #29 from Jakub Jelinek --- GCC 10.1 has been released.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #28 from Romain Geissler --- Hi David, Do you have plans to submit this patch for review when stage 1 of gcc 11 opens ? Cheers, Romain
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Andrew Pinski changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #27 from Andrew Pinski --- *** Bug 94367 has been marked as a duplicate of this bug. ***
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 David Malcolm changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 David Malcolm changed: What|Removed |Added Status|REOPENED|ASSIGNED CC||dmalcolm at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #26 from David Malcolm --- Created attachment 45674 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45674=edit Work-in-progress patch for a new warning for this (for GCC 10 stage 1) (I plan to post this to the mailing list once gcc 10 stage 1 opens)
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #25 from Jakub Jelinek --- No. We need at least some warning where non-OpenMP/OpenACC pragmas are in spots where it causes surprises to users.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #24 from Martin Liška --- Can the bug be marked as resolved?
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Manuel López-Ibáñez changed: What|Removed |Added CC||gary at intrepid dot com --- Comment #23 from Manuel López-Ibáñez --- *** Bug 71787 has been marked as a duplicate of this bug. ***
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #22 from Chen Gang --- (In reply to Jakub Jelinek from comment #21) > Author: jakub > Date: Fri Nov 27 08:59:55 2015 > New Revision: 230999 > > URL: https://gcc.gnu.org/viewcvs?rev=230999=gcc=rev This way looks OK to me. But for C++, it has no pr63326 issue, do we still need to modify gcc/cp/parser.c? pr42979 is related with this issue, more or less. May this patch also fix pr42979 by the way? If this patch really fix pr42979, we will still need gcc/cp/parser.c (both C and C++ have pr42979 issue). Thanks.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #21 from Jakub Jelinek --- Author: jakub Date: Fri Nov 27 08:59:55 2015 New Revision: 230999 URL: https://gcc.gnu.org/viewcvs?rev=230999=gcc=rev Log: PR c/63326 * c-parser.c (c_parser_compound_statement_nostart): If last_label is true, use pragma_stmt instead of pragma_compound as second c_parser_pragma argument. (c_parser_omp_ordered, c_parser_omp_target_update, c_parser_omp_target_enter_data, c_parser_omp_target_exit_data): Pass false as second argument to c_parser_skip_to_pragma_eol after diagnosing standalone directives used in pragma_stmt context. * parser.c (cp_parser_statement): Clear in_compound after labels. * gcc.dg/gomp/barrier-2.c (f2): Expect another error after label. * c-c++-common/gomp/pr63326.c: New test. * testsuite/libgomp.c/cancel-parallel-2.c (foo): Add semicolon in between case label and OpenMP standalone directives. * testsuite/libgomp.c++/cancel-parallel-2.C (foo): Likewise. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr63326.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/gomp/barrier-2.c trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.c++/cancel-parallel-2.C trunk/libgomp/testsuite/libgomp.c/cancel-parallel-2.c
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #19 from Chen Gang --- (In reply to Andrew Pinski from comment #18) > (In reply to Chen Gang from comment #17) > > I guess the diff below should be OK, I shall give a make check test. > > I would rather have the C front-end behavior for C++ rather than the > opposite way around. Because _Pragma are considered statements. For me, this bug is related with the demands (language definition), and C need not be part of C++. - For me, what cc1plus has done is OK: C++ looks that it always 'likes' more new features, and want to let the users (C++ programmer) use the language freely and in common sense. - But for C, if one feature is in discussing, it should not be treated as a common features (C standard is more stricter than C++). So we need not care about this 'bug' quite much (In real world, C programmers need not use #pragma in this way). In our case (this cc1 'bug'), Instead of returning the 'anbisous' result (it may cause misunderstanding for C/C++ programmers more or less), cc1 need report error during compiling.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #20 from Chen Gang --- (In reply to Andrew Pinski from comment #18) > (In reply to Chen Gang from comment #17) > > I guess the diff below should be OK, I shall give a make check test. > > I would rather have the C front-end behavior for C++ rather than the > opposite way around. Because _Pragma are considered statements. For me, this bug is related with the demands (language definition), and C need not be part of C++. - For me, what cc1plus has done is OK: C++ looks that it always 'likes' more new features, and want to let the users (C++ programmer) use the language freely and in common sense. - But for C, if one feature is in discussing, it should not be treated as a common features (C standard is more stricter than C++). So we need not care about this 'bug' quite much (In real world, C programmers need not use #pragma in this way). In our case (this cc1 'bug'), Instead of returning the 'anbisous' result (it may cause misunderstanding for C/C++ programmers more or less), cc1 need report error during compiling.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #18 from Andrew Pinski --- (In reply to Chen Gang from comment #17) > I guess the diff below should be OK, I shall give a make check test. I would rather have the C front-end behavior for C++ rather than the opposite way around. Because _Pragma are considered statements.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #17 from Chen Gang --- I guess the diff below should be OK, I shall give a make check test. diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index 7b10764..257 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -5170,7 +5170,9 @@ c_parser_statement_after_labels (c_parser *parser, vec *chain) c_parser_consume_token (parser); break; case CPP_PRAGMA: - c_parser_pragma (parser, pragma_stmt); + c_parser_error (parser, + "don't allow if, while, do, swith, or label" +); break; default: expr_stmt:
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #15 from Chen Gang --- For me, comment #9 is the reasonable fixing way. In real world, C/C++ programmers will/should not use #pragma in this way (use #pragma in place of the statement following an if, while, do, switch, or label). Another compilers maybe support #pragma in this way and check every #pragma details to determine to be as a statement or not, but in real world, this feature is useless (never need be used) for C/C++ programmers. It is worthless for gcc to support it. Could any members tell me the related usage cases in real world? Thanks.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #16 from Chen Gang --- Our C++ has no this issue. For precisely saying: cc1 has the issue, but cc1plus has no the issue (if use g++ build c programs, it has no issue; if use gcc build c++ programs, it has no issue, either). But still, for me, it is worthless for gcc and g++ to support this feature.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #14 from Chen Gang --- For gcc version 6.0.0 20151121 (experimental) (GCC), this issue is still existant. I shall try to fix it within this month (2015-11-30). Hope I can succeed.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #13 from Manuel López-Ibáñez --- Related bug: PR42979
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Maybe we should also warn about if (...) #pragma STDC ... foo (); both if we are treating the #pragma as stmt and if not. That is, if the #pragma appears in a place where that would make a difference.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Note, we already error out on OpenMP pragmas in such places, because the OpenMP standard requires that the pragmas aren't used in contexts where accepting them as statements or ignoring them would make a difference for parsing the function: For C/C++, a stand-alone directive may not be used in place of the statement following an if, while, do, switch, or label. See Appendix B for the formal grammar. so for other pragmas we could use similar conditions.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to steveren from comment #6) Seems the consensus is that it's not contrary to Standard, but it's agreed to be confusing and undesirable by everyone except the gcc maintainers :-) Not sure how you reached such conclusion, but it clearly misinterprets reality, otherwise this PR would be closed as INVALID already. I'm pretty sure if you submitted a patch making the behavior of all pragmas consistent with comment #9, this will be fixed by next week. (https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps) I'll take a lot of persuading that this isn't a reasonable thing to want to do. (Flagging the nasty, that is; purists who say you should never /do/ anything you need to warn people about need not apply :-) ) I'm not sure to which purists you are referring but, from my experience, GCC welcomes warnings that help people to write better code and prevent mistakes as long as patches are written and tested properly and do not generate too many hard-to-work-around false positives. New warnings are added in every release. Thus, I would encourage you to submit a patch and see for yourself.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #11 from steveren q@rsn-tech.co.uk --- (In reply to Manuel López-Ibáñez from comment #10) (In reply to steveren from comment #6) Seems the consensus is that it's not contrary to Standard, but it's agreed to be confusing and undesirable by everyone except the gcc maintainers :-) Not sure how you reached such conclusion, but it clearly misinterprets reality, otherwise this PR would be closed as INVALID already. Ok, my apologies. However, this bug /was/ closed as invalid before being reopened, and my own report was closed as invalid before being marked as a dupe of this one, so it's not entirely clear that there's a general feeling of a real problem that needs to be addressed. I'm pretty sure if you submitted a patch making the behavior of all pragmas consistent with comment #9, But I don't /want/ behaviour consistent with #9 (ie, warning that the usage is invalid), I want the usage to be valid /and/ sensible - ie, the same as other compilers. I suspect that's more difficult... Don't get me wrong - I'm not whingeing that other people should solve my problems for me without being prepared to get involved myself, but if this is WAD in the eyes of the majority, then I'll live with it sooner than create my own fork! So assuming it's not actually beyond somebody completely unfamiliar with the innards of gcc, what would be the response to a patch which changed #pragma message from 'statement' to 'not-a-statement'?
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to steveren from comment #11) So assuming it's not actually beyond somebody completely unfamiliar with the innards of gcc, what would be the response to a patch which changed #pragma message from 'statement' to 'not-a-statement'? I think that even if not a definitive solution, it would be a positive step towards understanding what would it take to change the behavior for specific #pragmas (since we cannot change how OMP #pragmas behave).
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||q@rsn-tech.co.uk --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 63612 has been marked as a duplicate of this bug. ***
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- When compiled with Clang, it returns 0 by the way.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #4) When compiled with Clang, it returns 0 by the way. So ... Pragma that are not recognized are ignored.
[Bug c/63326] whether a #pragma is a statement depends on the type of pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com --- #pragma STDC is functionally a declaration (it can only occur either outside external declarations or preceding all explicit declarations and statements inside a compound statement - each such pragma has the same wording, including FENV_ROUND in TS 18661-1). Thus, while those pragmas are not currently implemented in GCC, treating them as syntactical entities at the same level as declarations and statements would be fully in accordance with the standard.
