https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33719
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is a correct diagnostics. The firstprivate is about shared_var itself,
not what it points to, and for firstprivate on the working construct you need a
variable that is shared in the parallel and only privatized in the worksharing
region. Thus for firstprivate on an orphaned worksharing construct the
variable needs to be file scope/namespace scope, or static, or a reference that
binds to a shared variable.
"A list item that is private within a parallel region must not appear in a
firstprivate clause on a worksharing construct if any of the worksharing
regions arising from the worksharing construct ever bind to any of the parallel
regions arising from the parallel construct."
While the value of shared_var may be the same in all threads of a parallel, it
is still private in the parallel, consider what happens if you take the address
of shared_var, different threads will have different addresses. Function
parameters passed by value are like if you do { double *shared_var = something;
... } within parallel region, even if something is a shared variable,
shared_var is a local variable and as such it is predetermined to be private.
Just remove the bogus firstprivate(shared_var) in this case.
Note, if in C++ it is double *&shared_var, then firstprivate(shared_var) might
be ok, it will depend on whether what it binds to is shared or not.
See https://godbolt.org/z/l1v1NF that it is equally rejected by other compilers
too. They don't get the double *&shared_var case right, but properly diagnose
double *shared_var argument.
