{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":642016697,"defaultBranch":"main","name":"llvm-project","ownerLogin":"agozillon","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2023-05-17T16:29:21.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/8973308?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1725061792.0","currentOid":""},"activityList":{"items":[{"before":"eca9112402f207bf9a59affa383b5258e4e846a1","after":"79c444a67a2a8bd06ea6b6de74432c326c7edfc3","ref":"refs/heads/atd-with-alloca-dtype","pushedAt":"2024-09-21T04:00:00.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Implement N-D bounds and tidy up, still small bug with N-D parent subscripts to work through","shortMessageHtmlLink":"Implement N-D bounds and tidy up, still small bug with N-D parent sub…"}},{"before":"a648bd239f6b3e6da50ba6ed4d4a514428821a27","after":"eca9112402f207bf9a59affa383b5258e4e846a1","ref":"refs/heads/atd-with-alloca-dtype","pushedAt":"2024-09-21T03:58:26.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Implement N-D bounds and tidy up, still small bug with N-D parent subscripts to work through","shortMessageHtmlLink":"Implement N-D bounds and tidy up, still small bug with N-D parent sub…"}},{"before":"c208e7d96fe84628ed36a6b407b7924474e38b72","after":"a648bd239f6b3e6da50ba6ed4d4a514428821a27","ref":"refs/heads/atd-with-alloca-dtype","pushedAt":"2024-09-19T17:30:11.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"tmp notes","shortMessageHtmlLink":"tmp notes"}},{"before":"bf368dfa9ce370012ae3951d11c86b08484b4eb6","after":"c208e7d96fe84628ed36a6b407b7924474e38b72","ref":"refs/heads/atd-with-alloca-dtype","pushedAt":"2024-09-19T16:40:14.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"minor tidy up","shortMessageHtmlLink":"minor tidy up"}},{"before":"813891d65cf76eaa217df728358367c83c0d45f3","after":"bf368dfa9ce370012ae3951d11c86b08484b4eb6","ref":"refs/heads/atd-with-alloca-dtype","pushedAt":"2024-09-18T17:51:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Apply upstream allocatable member mapping with some minor modifications","shortMessageHtmlLink":"Apply upstream allocatable member mapping with some minor modifications"}},{"before":"215c3cba65d6e6198b3652a2345ea0a8f6638ee7","after":"813891d65cf76eaa217df728358367c83c0d45f3","ref":"refs/heads/atd-with-alloca-dtype","pushedAt":"2024-09-18T03:40:11.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"first working map indexing before clean up and further testing","shortMessageHtmlLink":"first working map indexing before clean up and further testing"}},{"before":null,"after":"215c3cba65d6e6198b3652a2345ea0a8f6638ee7","ref":"refs/heads/atd-with-alloca-dtype","pushedAt":"2024-08-30T23:49:52.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Apply upstream allocatable member mapping with some minor modifications","shortMessageHtmlLink":"Apply upstream allocatable member mapping with some minor modifications"}},{"before":"3e411d53a2fb81608dbfd58ea5d9127abfa411f1","after":"fc17907e10d8f125cf3e8775373f1b02185da2af","ref":"refs/heads/map-fix-and-tidy","pushedAt":"2024-08-23T15:32:15.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Fix rebase error","shortMessageHtmlLink":"Fix rebase error"}},{"before":null,"after":"fe2365ea1595b85d2e3fffcb55e53b0db181c914","ref":"refs/heads/dtype-squash-rebase-v3","pushedAt":"2024-08-07T16:27:56.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Fix mapping nullary binding tables via checking if there is any entries, more optimal approach would be to check if theres any dispatch operations inside of the target region (save some bandwidth from unrequired maps)","shortMessageHtmlLink":"Fix mapping nullary binding tables via checking if there is any entri…"}},{"before":"047caa96e28470d128b2fb833797436a6e70644a","after":"3e411d53a2fb81608dbfd58ea5d9127abfa411f1","ref":"refs/heads/map-fix-and-tidy","pushedAt":"2024-08-02T13:54:32.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP][Offload] Modify OMPMapInfoFinalization to work on a Module and add runtime test","shortMessageHtmlLink":"[Flang][OpenMP][Offload] Modify OMPMapInfoFinalization to work on a M…"}},{"before":null,"after":"7201a2c06e485766d655344f683a16b96ee860ec","ref":"refs/heads/dtype-squash-rebase-v2","pushedAt":"2024-07-25T17:01:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"PR for addition of addendum binding data mapping when available","shortMessageHtmlLink":"PR for addition of addendum binding data mapping when available"}},{"before":null,"after":"5c943d883d441dd115cc440d79c2130f13322e60","ref":"refs/heads/fix-for-dependent-PR","pushedAt":"2024-07-18T01:24:05.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][MLIR] Fix to mapping adding additional map pointer component for Descriptor mappings, helps to fix use_device_addr/ptr with these types\n\nThis PR basically adds an additional pointer binding for the descriptor base address. which we attach the user data to, it also makes sure that the mapping for the descriptor is always at a minimum \"to\" where possible, as regardless of whether or not we wish to map the user data the descriptor wrapping the data must be mapped across as the kernel will still make an attempt to access descriptor information to perform various tasks such as indexing into the user data. This may eventually be restricted a little further in the future to only allow descriptors to have a to mapping in cases where it's legal to have a to mapping (i.e. not legal on an exit directive).","shortMessageHtmlLink":"[Flang][MLIR] Fix to mapping adding additional map pointer component …"}},{"before":"07c893aa08bdc3e048dc27326a98b7d20c2e8f9f","after":"96134b2d67350af6d9516b6c77bd9c89d25cd209","ref":"refs/heads/map-clean-and-bugfix","pushedAt":"2024-07-08T13:52:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][MLIR][OpenMP] Align map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types\n\nThis PR aims unify the map argument generation across both the implicit capture (captured in a target region) and the explicit capture (process map), currently the varPtr field of the MapInfo for the same variable will be different depending on how it's captured. This PR tries to align that across the generations of MapInfoOp in the OpenMP lowering.\n\nCurrently, I have opted to utilise the rawInput (input memref to a HLFIR DeclareInfoOp) as opposed to the addr field which includes more information. The side affect of this is that we have to deal with BoxTypes less often, which will result in simpler maps in these cases. The negative side affect of this is that we don't have access to the bounds information through the resulting value, however, I believe the bounds information we require in our case is still appropriately stored in the map bounds, and this seems to be the case from testing so far.\n\nThe other fix is for cases where we end up with a BoxType argument into a function (certain assumed shape and sizes cases do this) that has no fir.ref wrapping it. As we need the Box to be a reference type to actually utilise the operation to access the base address stored inside and create the correct mappings we currently generate an intermediate allocation in these cases, and then store into it, and utilise this as the map argument, as opposed to the original.\n\nHowever, as we were not sharing the same intermediate allocation across all of the maps for a variable, this resulted in errors in certain cases when detatching/attatching the data e.g. via enter and exit.  This PR adjusts this for cases\n\nCurrently we only maintain tracking of all intermediate allocations for the current function scope, as opposed to module. Primarily as the only case I am aware of that this is required is in cases where we pass certain types of arguments to functions (so I opted to minimize the overhead of the pass for now). It could likely be extended to module scope if required if we find other cases where it's applicable and causing issues.","shortMessageHtmlLink":"[Flang][MLIR][OpenMP] Align map clause generation and fix issue with …"}},{"before":"476e4431912bb7078701f8c04df087d3610b934b","after":"047caa96e28470d128b2fb833797436a6e70644a","ref":"refs/heads/map-fix-and-tidy","pushedAt":"2024-07-05T20:55:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"remove accidental extraneous newlines","shortMessageHtmlLink":"remove accidental extraneous newlines"}},{"before":"8819ac0168b73abcd27536f339cd325beb08b093","after":"476e4431912bb7078701f8c04df087d3610b934b","ref":"refs/heads/map-fix-and-tidy","pushedAt":"2024-07-05T20:15:28.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] Align  map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types\n\nThis PR aims to unify the map argument generation behavior across both the implicit capture (captured in a target region) and the explicit capture (process map), currently the varPtr field of the MapInfo for the same variable will be different depending on how it's captured. This PR tries to align that across the generations of MapInfoOp in the OpenMP lowering.\n\nCurrently, I have opted to utilise the rawInput (input memref to a HLFIR DeclareInfoOp) as opposed to the addr field which includes more information. The side affect of this is that we have to deal with BoxTypes less often, which will result in simpler maps in these cases. The negative side affect of this is that we don't have access to the bounds information through the resulting value, however, I believe the bounds information we require in our case is still appropriately stored in the map bounds, and this seems to be the case from testing so far.\n\nThe other fix is for cases where we end up with a BoxType argument into a function (certain assumed shape and sizes cases do this) that has no fir.ref wrapping it. As we need the Box to be a reference type to actually utilise the operation to access the base address stored inside and create the correct mappings we currently generate an intermediate allocation in these cases, and then store into it, and utilise this as the map argument, as opposed to the original.\n\nHowever, as we were not sharing the same intermediate allocation across all of the maps for a variable, this resulted in errors in certain cases when detatching/attatching the data e.g. via enter and exit. This PR adjusts this for cases\n\nCurrently we only maintain tracking of all intermediate allocations for the current function scope, as opposed to module. Primarily as the only case I am aware of that this is required is in cases where we pass certain types of arguments to functions (so I opted to minimize the overhead of the pass for now). It could likely be extended to module scope if required if we find other cases where it's applicable and causing issues.","shortMessageHtmlLink":"[Flang][OpenMP] Align map clause generation and fix issue with non-sh…"}},{"before":null,"after":"8819ac0168b73abcd27536f339cd325beb08b093","ref":"refs/heads/map-fix-and-tidy","pushedAt":"2024-07-05T19:46:13.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] Align  map clause generation and fix issue with non-shared allocations for assumed shape/size descriptor types\n\nThis PR aims to unify the map argument generation behavior across both the implicit capture (captured in a target region) and the explicit capture (process map), currently the varPtr field of the MapInfo for the same variable will be different depending on how it's captured. This PR tries to align that across the generations of MapInfoOp in the OpenMP lowering.\n\nCurrently, I have opted to utilise the rawInput (input memref to a HLFIR DeclareInfoOp) as opposed to the addr field which includes more information. The side affect of this is that we have to deal with BoxTypes less often, which will result in simpler maps in these cases. The negative side affect of this is that we don't have access to the bounds information through the resulting value, however, I believe the bounds information we require in our case is still appropriately stored in the map bounds, and this seems to be the case from testing so far.\n\nThe other fix is for cases where we end up with a BoxType argument into a function (certain assumed shape and sizes cases do this) that has no fir.ref wrapping it. As we need the Box to be a reference type to actually utilise the operation to access the base address stored inside and create the correct mappings we currently generate an intermediate allocation in these cases, and then store into it, and utilise this as the map argument, as opposed to the original.\n\nHowever, as we were not sharing the same intermediate allocation across all of the maps for a variable, this resulted in errors in certain cases when detatching/attatching the data e.g. via enter and exit. This PR adjusts this for cases\n\nCurrently we only maintain tracking of all intermediate allocations for the current function scope, as opposed to module. Primarily as the only case I am aware of that this is required is in cases where we pass certain types of arguments to functions (so I opted to minimize the overhead of the pass for now). It could likely be extended to module scope if required if we find other cases where it's applicable and causing issues.","shortMessageHtmlLink":"[Flang][OpenMP] Align map clause generation and fix issue with non-sh…"}},{"before":null,"after":"07c893aa08bdc3e048dc27326a98b7d20c2e8f9f","ref":"refs/heads/map-clean-and-bugfix","pushedAt":"2024-07-05T14:05:32.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"7141445d3e2992fffd913f10e119ea15410c872c","after":"b28a90e0314faab704d0ff8417adcab6f542d78f","ref":"refs/heads/stack-reclaim-alloca-addressspace","pushedAt":"2024-06-27T01:12:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][Transform] Modify stack reclaim pass to use allocation address space when generating intrinsics\n\nThis PR aims to factor in the allocation address space provided by an architectures data layout when generating the intrinsic instructions, this allows them to be lowered later with the address spaces in tow. This aligns the intrinsic creation with the LLVM IRBuilder's https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/IRBuilder.h#L1053\n\nThis is also necessary for the below example to compile for OpenMP AMD GPU and not ICE the compiler in ISEL as AMD's stackrestore and stacksave are expected to have the appropriate allocation address space for AMD GPU.\n\nprogram main\n    integer(4), allocatable :: test\n    allocate(test)\n\n!$omp target map(tofrom:test)\n    do i = 1, 10\n      test = test + 50\n    end do\n!$omp end target\n\n  deallocate(test)\nend program\n\nThe PR also fixes the issue I opened a while ago which hits the same error when compiling for AMDGPU: https://github.com/llvm/llvm-project/issues/82368\n\nAlthough, you have to have the appropriate GPU LIBC and Fortran offload runtime (both compiled for AMDGPU) added to the linker for the command or it will reach another ISEL error and ICE weirdly. But with the pre-requisites it works fine with this PR.","shortMessageHtmlLink":"[Flang][Transform] Modify stack reclaim pass to use allocation addres…"}},{"before":null,"after":"7141445d3e2992fffd913f10e119ea15410c872c","ref":"refs/heads/stack-reclaim-alloca-addressspace","pushedAt":"2024-06-27T01:11:23.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"39ddaffa5a9311f06011a9644cb96bde2fa2717d","after":"892b7254a26a2163ba91962584d3e366b7a2f667","ref":"refs/heads/common-block-map-pr","pushedAt":"2024-06-25T14:54:13.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Update test to avoid utilisation of DeclareOp","shortMessageHtmlLink":"Update test to avoid utilisation of DeclareOp"}},{"before":"b98c4a3e5876b6f96ab3fe00d7977236f54bceb3","after":"39ddaffa5a9311f06011a9644cb96bde2fa2717d","ref":"refs/heads/common-block-map-pr","pushedAt":"2024-06-24T20:04:20.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Remove cg-rewrite from fir-opt as it's added in a seperate PR","shortMessageHtmlLink":"Remove cg-rewrite from fir-opt as it's added in a seperate PR"}},{"before":"2fe98b9b6c6ea39e3073f615b0d60af9f14dc1e0","after":"b98c4a3e5876b6f96ab3fe00d7977236f54bceb3","ref":"refs/heads/common-block-map-pr","pushedAt":"2024-06-24T20:02:17.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"Add two more regression tests","shortMessageHtmlLink":"Add two more regression tests"}},{"before":null,"after":"eb2844fa02ca80be24c0e818815ad00c188bfcfc","ref":"refs/heads/add-pass-to-openmp-fir-test","pushedAt":"2024-06-24T18:11:28.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] Add --cg-rewrite pass to convert-to-llvm-openmp-and-fir.fir test\n\nCurrently this is missing from the fir-opt command in this test, which\nmeans we can't use certain fir.operations inside of the test without\ncausing verification issues. As an example fir::DeclareOp, which I\nbelieve the cg-rewrite pass normally converts to fir::cg::XDeclareOp prior to\nCodeGen'ng to LLVM-IR.\n\nPerhaps, there's a reason for not including this option in the command list\noriginally that I am not aware of! But it would be helpful to enable this\npass to allow the full (or at least a wider) range of FIR operations to be\nused within the test cases.","shortMessageHtmlLink":"[Flang][OpenMP] Add --cg-rewrite pass to convert-to-llvm-openmp-and-f…"}},{"before":"288903230e13a68ec7c314a082bbd8489fc01280","after":"b4927a9e6fb1bb4c49c2153e74e66fbf99153a51","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-20T22:43:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] Squashed allocatable PR","shortMessageHtmlLink":"[Flang][OpenMP] Squashed allocatable PR"}},{"before":"04fc084898199add98775a36dda066bbb7ef4133","after":"288903230e13a68ec7c314a082bbd8489fc01280","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-19T23:38:51.000Z","pushType":"push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"91e1d687834342f356e13b2aa24d34b8b9ce8e14","after":"04fc084898199add98775a36dda066bbb7ef4133","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-18T22:15:14.000Z","pushType":"push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"2ea460236ab0ad0a0363198c212b513e5960c8bd","after":"91e1d687834342f356e13b2aa24d34b8b9ce8e14","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-17T23:35:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"c6b8c06df452a6e322e88e0c321f2e99ff9f8b5d","after":"fb4cb0f1755871addac02db936fa87540542d087","ref":"refs/heads/unnamed-main-symbol-error","pushedAt":"2024-06-17T19:49:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"},"commit":{"message":"[Flang][OpenMP] More elegantly handle declare target in unnamed program\n\nThis PR is related to the following issue:\n\nhttps://github.com/llvm/llvm-project/issues/63362\n\nIt tries to solve the crash (which is now slightly different, since the\nissue has been languishing for a while sorry about that I missed\nthe original issue ping).\n\nThe crash occurs due to trying to access the symbol of an undefined/unnamed main when trying to find a declare\ntarget symbol that has not been specified (but can be\nassumed based on it's residence in a function or interface).\n\nThe solution in this PR will check if we're trying to retrieve\na main symbol, and then if that is the case, we make sure\nit exists (due to being named) before we attempt to retrieve\nit, this avoids the crash.\n\nHowever, that's only part of the issue in the above example,\nthe other is the significant amount of nested directives, I\nthink we are still a little while away from handling this, I\nhave added a reduced variation of the test in the issue\nas a replicator which contains a lesser number of nesting\ndirectives. To push the issue along further, it will likely be\na case of working through a number of variations of\nnested directives in conjunction with target + parallel.\n\nHowever, this PR pushes the issue above to the point where\nthe issue encountered is identical to the following:\nhttps://github.com/llvm/llvm-project/issues/67231","shortMessageHtmlLink":"[Flang][OpenMP] More elegantly handle declare target in unnamed program"}},{"before":null,"after":"c6b8c06df452a6e322e88e0c321f2e99ff9f8b5d","ref":"refs/heads/unnamed-main-symbol-error","pushedAt":"2024-06-17T19:47:36.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}},{"before":"326afe2a318d51d6ab194930323a2baba4887130","after":"2ea460236ab0ad0a0363198c212b513e5960c8bd","ref":"refs/heads/dtype-squash-rebase","pushedAt":"2024-06-14T21:03:19.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"agozillon","name":null,"path":"/agozillon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/8973308?s=80&v=4"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0yMVQwNDowMDowMC4wMDAwMDBazwAAAAS8hlWF","startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0yMVQwNDowMDowMC4wMDAwMDBazwAAAAS8hlWF","endCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wNi0xNFQyMTowMzoxOS4wMDAwMDBazwAAAARl1-Pq"}},"title":"Activity · agozillon/llvm-project"}