https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104722
--- Comment #4 from Hubert Degaudenzi <hubert.degaudenzi at gmail dot com> --- (In reply to Jonathan Wakely from comment #3) > (In reply to Andrew Pinski from comment #1) > > I think this code is undefined as the order of the addition is not specified > > for std::accumulate > > It is specified for std::accumulate, but the _GLIBCXX_PARALLEL mode breaks > the guarantees by performing the additions in parallel, so not in the same > order. I am no compiler specialist, but this looks still wrong to me. Even if the additions are done in a completely random order, the result must stay the same. I am well aware of rounding issues with additions and subtraction of big and small items for floating point numbers and other possible pitfalls, but here we are only dealing with sheer additions. And we get a difference of about 8 orders of magnitude (!). > The parallel mode was an experiment that will be removed from libstdc++ at > some point. You might want to try the C++17 parallel algos instead, I can give it a shot. But our team is still bound to the C++14 standard, and there might be some time before we change this. > or just > accept that parallel mode evaluates the algorithm differently (that's the > whole point - it breaks the work into chunks to be evaluated in multiple > threads). Please reconsider. Even if it evaluates differently, the final reduction should behave.
