public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/52600] New: OpenMP: declaration as structured block
@ 2012-03-16 11:04 burnus at gcc dot gnu.org
2012-03-26 10:24 ` [Bug c/52600] " jakub at gcc dot gnu.org
2021-12-12 3:23 ` pinskia at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-03-16 11:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52600
Bug #: 52600
Summary: OpenMP: declaration as structured block
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: openmp, rejects-valid
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: burnus@gcc.gnu.org
Found at
http://openmp.org/forum/viewtopic.php?f=10&t=1329&sid=58cf62c9cbfc7fee81768f053e079615
... and there believed to be valid. GCC rejects the following:
#pragma omp task
int x = foo();
with
error: expected expression before ‘int’
While the following, syntactically identical (?), is accepted:
#pragma omp task
{ int x = foo(); }
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c/52600] OpenMP: declaration as structured block
2012-03-16 11:04 [Bug c/52600] New: OpenMP: declaration as structured block burnus at gcc dot gnu.org
@ 2012-03-26 10:24 ` jakub at gcc dot gnu.org
2021-12-12 3:23 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-03-26 10:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52600
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |rth at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-26 10:17:02 UTC ---
In C++ we accept this, in C we don't (we call c_parser_statement, but
declarations aren't handled by that, due to the allowing/disallowing of mixing
of declarations and statements in C99 vs. C90).
I guess we could move the loop body from c_parser_compound_statement_nostart
to a new function and use it there as well as in c_parser_omp_structured_block,
c_parser_omp_{parallel,task} and c_parser_omp_sections_scope.
It is very ugly to allow there declarations though, that means code behaves
very differently between -fopenmp and -fno-openmp - in the former case the
declared var would go out of scope immediately, in the latter would be around
until closing }.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c/52600] OpenMP: declaration as structured block
2012-03-16 11:04 [Bug c/52600] New: OpenMP: declaration as structured block burnus at gcc dot gnu.org
2012-03-26 10:24 ` [Bug c/52600] " jakub at gcc dot gnu.org
@ 2021-12-12 3:23 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-12 3:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52600
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2021-12-12
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
hmm, clang also rejects it for the C case.
Though it would be interesting because we now allow:
int foo1(void);
void foo()
{
a: int x = foo1();
}
But still reject:
int foo1(void);
void foo()
{
#pragma omp task
a: int x = foo1();
}
While clang accepts the case with labels.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-12-12 3:23 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-16 11:04 [Bug c/52600] New: OpenMP: declaration as structured block burnus at gcc dot gnu.org
2012-03-26 10:24 ` [Bug c/52600] " jakub at gcc dot gnu.org
2021-12-12 3:23 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).