[Openmp-dev] exception throwing from a copy constructor for a firstprivate

[Joachim Protze via Openmp-dev]

Hi Natalia,

I redirected this question to the OpenMP language committee. I think 
this case might be an oversight. The spec does not define, when the copy 
constructor is used to initialize the variable.

Best
Joachim

Am 14.12.21 um 20:18 schrieb Natalia Glagoleva via Openmp-dev:
> In Standard 5.2 I see these two phrases:
> 
> (p 48, 16-19) A throw executed inside a region that arises from a 
> thread-limiting directive must cause 17 execution to resume within the 
> same region, and the same thread that threw the exception must 18 catch 
> it. If the directive is also exception-aborting then whether the 
> exception is caught or the 19 throw results in runtime error termination 
> is implementation defined.
> 
> (p 617, 3-4) Whether a throw executed inside a region that arises from 
> an exception-aborting directive 4 results in runtime error termination 
> is implementation defined (see Section 3.1).
> 
> I am trying the attached test,
> 
> clang -O0 task_ftp_EH3_noeh.cpp  -DNOISY -DCOUNT=2 -fopenmp
> 
> The essential part:
> 
> void main_test(MyObject* pTree, int i) {
> 
>      if (!pTree) return;
> 
> #pragma omp parallel default(none) shared(i, pTree) 
> num_threads(NUM_THREADS)
> 
> #pragma omp single
> 
>      {
> 
>          while (pTree) {
> 
>              try {
> 
>                  MyObject tree(*pTree);
> 
> #pragma omp task firstprivate(i, tree)
> 
>                  {
> 
>                      …
> 
>                      main_test(tree.right, i + 4);
> 
>                  }
> 
>                    …
> 
>              }
> 
>              catch (std::exception) {
> 
>                  …
> 
>              }
> 
>              …
> 
>          }
> 
>      }
> 
> }
> 
> Where copy constructor for ‘tree’ throws when it’s called for 
> firstprivate clause (called second time).
> 
> My assumption was that the clause is computed in the ‘single’ region, 
> not ‘task’ region, and catch is there too, so I thought that technically 
> it should be legal and catch should work.
> 
> This is hanging in the runtime, verified with llvm 13 release.
> 
> Is it a bug?
> 
> Thank you,
> 
> Natalia Glagoleva
> 
> 
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>