[Bug c++/34517] New: INCOROUT: C++ OpenMP lastprivate

[Bug c++/34517] New: INCOROUT: C++ OpenMP lastprivate

[hailijuan at gmail dot com]

testcase b.C attached to show the problem. "a.ai += addnum" refers to distinct
objects therefore a.ai finally equals to 7 rather than 28 (now it is!) when
reaching printf.

micro# g++ b.C -fopenmp
micro# ./a.out
constructor
constructor
constructor
constructor
constructor
ai: 28  exp: 7  af: 28.000000  exp: 7
micro# g++ -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /import/dr2/starlex/orig/trunk/configure
--prefix=/import/dr3/s10/gcc-4.3/ --enable-languages=c,c++,fortran
--disable-gnattools --with-mpfr=/ws/gccfss/tools --with-gmp=/ws/gccfss/tools
Thread model: posix
gcc version 4.3.0 20070912 (experimental) (GCC)


-- 
           Summary: INCOROUT: C++ OpenMP lastprivate
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hailijuan at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34517

[Bug c++/34517] INCOROUT: C++ OpenMP lastprivate

[hailijuan at gmail dot com]

------- Comment #1 from hailijuan at gmail dot com  2007-12-18 06:07 -------
Created an attachment (id=14789)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14789&action=view)
C++ OpenMP testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34517

[Bug c++/34517] INCOROUT: C++ OpenMP lastprivate

[jakub at gcc dot gnu dot org]

------- Comment #2 from jakub at gcc dot gnu dot org  2007-12-18 11:39 -------
IMHO it can validly print 7, 14, 21 or 28.  See OpenMP 2.5, section 2.5.2:
"The method of scheduling the structured blocks among threads in the team is
implementation defined."
Also, data sharing clause is sections construct clause rather than section
directive clause, so no matter how many section directives you have, the
constructor/destructor will be called as many times as there are threads in the
team.  GCC schedules the first not yet processed #pragma omp section block
to the first available thread, doesn't do assign different blocks to different
threads no matter whether they are available or not.  So, if e.g. one
(typically master) thread is available some time before all other threads and
there isn't
really any significant work to do in the block, so it finishes almost
instantly,
it might very well win the next section block as well, because other threads
are
still being set up.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34517