Meinersbur wrote: This change makes sense to me. In principle, the information of generated loops is only needed in dependent contexts (not yet fully expanded templates); elsewhere we get the loop nest structure from `getTransformedStmt()`. The use in `doForAllLoops` is meant to delay evaluation for when the template is instantiated. A QoI would be able to check the loop structure within a template from this information, even without it needed to be instantiated. I don't think we should remove the information only to be re-added again for #139293.
I think a test case could be possible under the following conditions: 1. reverse construct (number of generated loops of `tile` is positive in either case) 2. In a template definition (dependent context) 3. Loop bounds of reversed loop depends on template parameter (seeing https://github.com/llvm/llvm-project/blob/dedef408d759b50360ae8a7ef2ba13ba6931b4d8/clang/lib/Sema/SemaOpenMP.cpp#L15136 this might not be necessary) 4. Another construct applied to the generated loop of the `reverse` (e.g. unroll) In that case `doForAllLoops` should `break` instead of `return` causing the following code to execute on the `OMPReverseConstruct` itself instead of a loop, causing an assertion to fail. https://github.com/llvm/llvm-project/pull/140532 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
