On 18/06/26 02:02, Harald Anlauf wrote:
External email: Use caution opening links or attachments
Am 17.06.26 um 11:09 AM schrieb Richard Biener:
On Wed, Jun 17, 2026 at 10:57 AM Dhruv Chawla <[email protected]> wrote:
On 17/06/26 14:03, Kyrylo Tkachov wrote:
Yes, that is what it turned out to be - a caller-allocated stack array
used as return storage for a callee (`compute` in the test case) got
hoisted outside the loop (as its address was loop-invariant for a
single thread), so multiple threads ended up writing to the same address
thus leading to garbage output. This doesn't occur in the pot3d function,
so it is safe to ignore this bug.
But it must be possible to classify a conservatively safe subset of
do concurrent loops from inside the frontend? I'd really prefer that.
I do also see the data race for the temporary for the array-valued
function result of compute with -fsanitize=thread, which does not
occur when I use an ordinary OpenMP do loop instead of do concurrent.
So how does OpenMP annotate the temporary (it should be PRIVATE)?
And can this be used to annotate frontend-generated temporaries
for the auto-parallelizer?
(BTW: the testcase runs a factor of 10 faster for me when I replace
tmp(k) = tmp(k) + (-1.0_real64)**(j+1) / real( 2*j-1 )
by
tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1, real64)
because the power of integer (-1) is expanded inline.)
autopar is essentially unmaintained ... but clearly the can_be_parallel
flag isn't correct for the IL as-is? While I looked into autpar years
ago I don't remember much in what guarantees it makes, but I think
all of the safety is with the dependence analysis we skip with
can_be_parallel annotated loops.
I think the loop is fine (Fortran-wise).
I also tried to use an explicit temporary and making compute
a subroutine, like
...
real(real64), dimension(nsplit) :: mytmp
...
do concurrent (i = 1:nsplit) local (mytmp)
call compute( low(i), high(i) , mytmp)
pi(i) = sum (mytmp)
end do
This avoids frontend-generated temporaries, but still has the same
data race.
Cheers,
Harald
Hi all,
Thank you for your replies. I do wonder, what are the next steps
here? Would it be a good idea to fix the bug in the auto-parallelizer?
I can take a shot at that, but it is something I am not familiar with
plus it also requires emitting annot_expr_parallel_kind in some way
anyways. The other solution is to improve the ivdep analysis but that
also seems like quite the mountain to climb.
I would really like it if this can potentially be fixed in the GCC 17
timeframe as this is a real (and very large) performance issue.
Side note: I did notice an interesting thing with flang where it would
emit collapse(n) based on the rank of the loops to flatten
everything. Could GCC do that as well? Would it make a
difference here?
--
Regards,
Dhruv
