https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to sandra from comment #5)
> Tobias, it looks to me like you missed the connection ...
No, I didn't - I did link it (cf. top of comment 3) — but I just cannot read
:-/
Hence, for
(1) *teams* *parallel* *for* parallel for
(2) *teams* *parallel* for parallel *for*
(3) *teams* parallel for *parallel* *for*
we now have
p = {1,2,3,4,5} → score = {1,2,4,8,16}
Thus:
(1) 1 + 2 + 4 = 9
(2) 1 + 2 + 16 = 19
(3) 1 + 8 + 16 = 25
such that (3) wins → and, hence, either of
(f15) match (construct={parallel},user={condition(score(19):1)}) /* 8+19 */
(f16) match (implementation={atomic_default_mem_order(score(27):seq_cst)})
as 27 > 25 - and OpenMP states that it is implementation defined which of the
score = 27 variant is used.
* * *
Thus, I concur that there is an ordering and, hence, scoring bug.
* * *
> I don't know if anybody wants to tackle a bug fix for this code for GCC 14.
I think we don't - we are too close to the release. This has been implemented
since 2019, 'score()' is not implemented in Clang 18, and code like that is
unlikely to be often used. And the code is non-trivial. - All speaks against
rushing to do an implementation for GCC 14.
