https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102985
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- That testcase doesn't seem to be valid to me. While we have only explicit "A list item that is private within a parallel region, or that appears in the reduction clause of a parallel construct, must not appear in a lastprivate clause on a worksharing construct if any of the corresponding worksharing regions ever binds to any of the corresponding parallel regions." rule and not something similar for teams, it is exactly the same thing and same problem. If lastprivate writes to a var that is private in the outer context, that means that one lucky thread (or team) will get the final value stored and all others will not touch that var. So, without num_teams(1) those testcases would be both racy and UB... I think we want to discuss this in the language committee. On the GCC side, if we don't reject it, we'd ICE on it during omp lowering. Your Fortran testcase is different, res is declared outside of teams (and target), it is implicitly firstprivate on target and implicitly shared on teams. To get the same effect, you'd either need to add private(res) on teams, or block with integer :: res in it around the teams body.
