From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15632 invoked by alias); 20 Sep 2013 11:16:56 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 15577 invoked by uid 48); 20 Sep 2013 11:16:52 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libgomp/58482] gomp4: user defined reduction produce wrong result Date: Fri, 20 Sep 2013 11:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgomp X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-09/txt/msg01495.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58482 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- Yeah, the testcase is just wrong. The way OpenMP reductions work is that in the loop the reduction variable(s) are privatized, i.e. either each thread (for e.g. #pragma omp for) or each SIMD lane (for #pragma omp simd) gets its own copy of that var, either default constructed (C++98 wording; for UDRs with missing initializer clause), or initialized otherwise (see the standard for details), in the loop everything is done on the privatized variable and finally at the end the reduction operation is performed on the original variable, calling the combiner expression with omp_out being the original variable and omp_in being the privatized var, for each of the privatized variables. But your testcase obviously can't work properly in that case, because your reduction operation can't cope properly with being performed more than once. If you subtract the array element values from the counter, then if they are all positive, you'll get negative number, while if you subtract them from the privatized var, all those privatized vars will have negative counter, but then you subtract those negative numbers from the original var counter and get positive number. There is a reason why reduction (-:int_var) is actually implemented as addition rather than subtraction... In your testcase, you'd want a different operation to be used in the reduction combiner, one that would add things rather than subtract.