-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[flang][openacc] Allow if clause on atomic directives #135451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@llvm/pr-subscribers-openacc @llvm/pr-subscribers-flang-parser Author: Valentin Clement (バレンタイン クレメン) (clementval) ChangesThe new version of the OpenACC specification will allow the if clause on the atomic directives. Allow it in OpenACC dialect will need to be updated to support it as well. Full diff: https://github.com/llvm/llvm-project/pull/135451.diff 4 Files Affected:
diff --git a/flang/include/flang/Parser/parse-tree.h b/flang/include/flang/Parser/parse-tree.h
index eeb438991feee..0c2a5de3b71d2 100644
--- a/flang/include/flang/Parser/parse-tree.h
+++ b/flang/include/flang/Parser/parse-tree.h
@@ -5244,21 +5244,23 @@ EMPTY_CLASS(AccEndAtomic);
// ACC ATOMIC READ
struct AccAtomicRead {
TUPLE_CLASS_BOILERPLATE(AccAtomicRead);
- std::tuple<Verbatim, Statement<AssignmentStmt>, std::optional<AccEndAtomic>>
+ std::tuple<Verbatim, AccClauseList, Statement<AssignmentStmt>,
+ std::optional<AccEndAtomic>>
t;
};
// ACC ATOMIC WRITE
struct AccAtomicWrite {
TUPLE_CLASS_BOILERPLATE(AccAtomicWrite);
- std::tuple<Verbatim, Statement<AssignmentStmt>, std::optional<AccEndAtomic>>
+ std::tuple<Verbatim, AccClauseList, Statement<AssignmentStmt>,
+ std::optional<AccEndAtomic>>
t;
};
// ACC ATOMIC UPDATE
struct AccAtomicUpdate {
TUPLE_CLASS_BOILERPLATE(AccAtomicUpdate);
- std::tuple<std::optional<Verbatim>, Statement<AssignmentStmt>,
+ std::tuple<std::optional<Verbatim>, AccClauseList, Statement<AssignmentStmt>,
std::optional<AccEndAtomic>>
t;
};
@@ -5268,7 +5270,7 @@ struct AccAtomicCapture {
TUPLE_CLASS_BOILERPLATE(AccAtomicCapture);
WRAPPER_CLASS(Stmt1, Statement<AssignmentStmt>);
WRAPPER_CLASS(Stmt2, Statement<AssignmentStmt>);
- std::tuple<Verbatim, Stmt1, Stmt2, AccEndAtomic> t;
+ std::tuple<Verbatim, AccClauseList, Stmt1, Stmt2, AccEndAtomic> t;
};
struct OpenACCAtomicConstruct {
diff --git a/flang/lib/Parser/openacc-parsers.cpp b/flang/lib/Parser/openacc-parsers.cpp
index fb731ee52cbba..072eba99826a1 100644
--- a/flang/lib/Parser/openacc-parsers.cpp
+++ b/flang/lib/Parser/openacc-parsers.cpp
@@ -187,22 +187,25 @@ TYPE_PARSER(construct<AccBeginCombinedDirective>(
// 2.12 Atomic constructs
TYPE_PARSER(construct<AccEndAtomic>(startAccLine >> "END ATOMIC"_tok))
-TYPE_PARSER("ATOMIC" >>
- construct<AccAtomicRead>(verbatim("READ"_tok) / endAccLine,
- statement(assignmentStmt), maybe(Parser<AccEndAtomic>{} / endAccLine)))
+TYPE_PARSER("ATOMIC" >> construct<AccAtomicRead>(verbatim("READ"_tok),
+ Parser<AccClauseList>{} / endAccLine,
+ statement(assignmentStmt),
+ maybe(Parser<AccEndAtomic>{} / endAccLine)))
-TYPE_PARSER("ATOMIC" >>
- construct<AccAtomicWrite>(verbatim("WRITE"_tok) / endAccLine,
- statement(assignmentStmt), maybe(Parser<AccEndAtomic>{} / endAccLine)))
+TYPE_PARSER("ATOMIC" >> construct<AccAtomicWrite>(verbatim("WRITE"_tok),
+ Parser<AccClauseList>{} / endAccLine,
+ statement(assignmentStmt),
+ maybe(Parser<AccEndAtomic>{} / endAccLine)))
TYPE_PARSER("ATOMIC" >>
- construct<AccAtomicUpdate>(maybe(verbatim("UPDATE"_tok)) / endAccLine,
- statement(assignmentStmt), maybe(Parser<AccEndAtomic>{} / endAccLine)))
+ construct<AccAtomicUpdate>(maybe(verbatim("UPDATE"_tok)),
+ Parser<AccClauseList>{} / endAccLine, statement(assignmentStmt),
+ maybe(Parser<AccEndAtomic>{} / endAccLine)))
TYPE_PARSER("ATOMIC" >>
- construct<AccAtomicCapture>(verbatim("CAPTURE"_tok) / endAccLine,
- statement(assignmentStmt), statement(assignmentStmt),
- Parser<AccEndAtomic>{} / endAccLine))
+ construct<AccAtomicCapture>(verbatim("CAPTURE"_tok),
+ Parser<AccClauseList>{} / endAccLine, statement(assignmentStmt),
+ statement(assignmentStmt), Parser<AccEndAtomic>{} / endAccLine))
TYPE_PARSER(
sourced(construct<OpenACCAtomicConstruct>(Parser<AccAtomicRead>{})) ||
diff --git a/flang/test/Semantics/OpenACC/acc-atomic-validity.f90 b/flang/test/Semantics/OpenACC/acc-atomic-validity.f90
index ba68031b0f18b..07fb864695737 100644
--- a/flang/test/Semantics/OpenACC/acc-atomic-validity.f90
+++ b/flang/test/Semantics/OpenACC/acc-atomic-validity.f90
@@ -10,6 +10,7 @@ program openacc_atomic_validity
integer :: i
integer, parameter :: N = 256
integer, dimension(N) :: c
+ logical :: l
!$acc parallel
@@ -23,27 +24,58 @@ program openacc_atomic_validity
!$acc atomic write
c(i) = 10
+ !$acc atomic write if(l)
+ c(i) = 10
+
!$acc atomic write
c(i) = 10
!$acc end atomic
+ !$acc atomic write if(.true.)
+ c(i) = 10
+ !$acc end atomic
+
!$acc atomic read
i = c(i)
+
+ !$acc atomic read if(.true.)
+ i = c(i)
!$acc atomic read
i = c(i)
!$acc end atomic
+ !$acc atomic read if(l)
+ i = c(i)
+ !$acc end atomic
+
+ !ERROR: FINALIZE clause is not allowed on the ATOMIC READ FINALIZE IF(L)
+ !$acc atomic read finalize if(l)
+ i = c(i)
+ !$acc end atomic
+
!$acc atomic capture
c(i) = i
i = i + 1
!$acc end atomic
+ !$acc atomic capture if(l .EQV. .false.)
+ c(i) = i
+ i = i + 1
+ !$acc end atomic
+
!$acc atomic update
!ERROR: RHS of atomic update statement must be scalar
!ERROR: LHS of atomic update statement must be scalar
c = c + 1
+ !$acc atomic update if(i == 0)
+ c(i) = c(i) + 1
+
+ !ERROR: At most one IF clause can appear on the ATOMIC UPDATE IF(I == 0) IF(.TRUE.)
+ !$acc atomic update if(i == 0) if(.true.)
+ c(i) = c(i) + 1
+
!$acc end parallel
end program openacc_atomic_validity
diff --git a/llvm/include/llvm/Frontend/OpenACC/ACC.td b/llvm/include/llvm/Frontend/OpenACC/ACC.td
index 8729d4505205b..c77988b21c1e3 100644
--- a/llvm/include/llvm/Frontend/OpenACC/ACC.td
+++ b/llvm/include/llvm/Frontend/OpenACC/ACC.td
@@ -270,6 +270,7 @@ def ACCC_Unknown : Clause<"unknown"> {
// 2.12
def ACC_Atomic : Directive<"atomic"> {
+ let allowedOnceClauses = [VersionedClause<ACCC_If, 34>];
let association = AS_Block;
let category = CA_Executable;
}
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't read any of the parser stuff, but everything looks ok to me anyway.
@razvanlupusoru Are you ok with this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
The new version of the OpenACC specification will allow the if clause on the atomic directives. Allow it in `ACC.td` and update the parse node and parser in flang to support it. OpenACC dialect will need to be updated to support it as well.
#135372) …uses The Flang implemenation of OpenACC uses a .td file in the llvm/Frontend directory to determine appertainment in 4 categories: -Required: If this list has items in it, the directive requires at least 1 of these be present. -AllowedExclusive: Items on this list are all allowed, but only 1 from the list may be here (That is, they are exclusive of eachother). -AllowedOnce: Items on this list are all allowed, but may not be duplicated. Allowed: Items on this list are allowed. Note th at the actual list of 'allowed' is all 4 of these lists together. This is a draft patch to swtich Clang over to use those tables. Surgery to get this to happen in Clang Sema was somewhat reasonable. However, some gaps in the implementations are obvious, the existing clang implementation disagrees with the Flang interpretation of it. SO, we're keeping a task list here based on what gets discovered. Changes to Clang: - [x] Switch 'directive-kind' enum conversions to use tablegen See ff1a7bd - [x] Switch 'clause-kind' enum conversions to use tablegen See ff1a7bd - [x] Investigate 'parse' test differences to see if any new disagreements arise. - [x] Clang/Flang disagree as to whether 'collapse' can be multiple times on a loop. Further research showed no prose to limit this, and the comment on the clang implementation said "no good reason to allow", so no standards justification. - [x] Clang/Flang disagree whether 'num_gangs' can appear >1 on a compute/combined construct. This ended up being an unjustified restriction. - [x] Clang/Flang disagree as to the list of required clauses on a 'set' construct. My research shows that Clang mistakenly included 'if' in the list, and that it should be just 'default_async', 'device_num', and 'device_type'. - [x] Order of 'at least one of' diagnostic has changed. Tests were updated. - [x] Ensure we are properly 'de-aliasing' clause names in appertainment checks? - [x] What is 'shortloop'? 'shortloop' seems to be an old non-standard extension that isn't supported by flang, but is parsed for backward compat reasons. Clang won't parse, but we at least have a spot for it in the clause list. - [x] Implemented proposed change for 'routine' gang/worker/vector/seq. (see issue 539) - [x] Implement init/shutdown can only have 1 'if' (see issue 540) - [x] Clang/Flang disagree as to whether 'tile' is permitted more than once on a 'loop' or combined constructs (Flang prohibits >1). I see no justification for this in the standard. EDIT: I found a comment in clang that I did this to make SOMETHING around duplicate checks easier. Discussion showed we should actually have a better behavior around 'device_type' and duplicates, so I've since implemented that. - [x] Clang/Flang disagree whether 'gang', 'worker', or 'vector' may appear on the same construct as a 'seq' on a 'loop' or 'combined'. There is prose for this in 2022: (a gang, worker, or vector clause may not appear if a 'seq' clause appears). EDIT: These don't actually disagree, but aren't in the .td file, so I restored the existing code to do this. - [x] Clang/Flang disagree on whether 'bind' can appear >1 on a 'routine'. I believe line 3096 (A bind clause may not bind to a routine name that has a visible bind clause) makes this limitation (Flang permits >1 bind). we discussed and decided this should have the same rules as worker/vector/etc, except without the 'exactly 1 of' rule (so no dupes in individual sections). - [x] Clang/Flang disagree on whether 'init'/'shutdown' can have multiple 'device_num' clauses. I believe there is no supporting prose for this limitation., We decided that `device_num` should only happen 1x. - [x] Clang/Flang disagree whether 'num_gangs' can appear >1 on a 'kernels' construct. Line 1173 (On a kernels construct, the num_gangs clause must have a single argument) justifies limiting on a per-arguement basis, but doesn't do so for multiple num_gangs clauses. WE decided to do this with the '1-per-device-type' region for num_gangs, num_workers, and vector_length, see openacc bug here: OpenACC/openacc-spec#541 Changes to Flang: - [x] Clang/Flang disgree on whether 'atomic' can take an 'if' clause. This was added in OpenACC3.3_Next See #135451 - [x] Clang/Flang disagree on whether 'finalize' can be allowed >1 times on a 'exit_data' construct. see #135415. - [x] Clang/Flang disagree whether 'if_present' should be allowed >1 times on a 'host_data'/'update' construct. see #135422 - [x] Clang/Flang disagree on whether 'init'/'shutdown' can have multiple 'device_type' clauses. I believe there is no supporting prose for this limitation. - [ ] SEE change for num_gangs/etc above. Changes that need discussion/research:
llvm#135372) …uses The Flang implemenation of OpenACC uses a .td file in the llvm/Frontend directory to determine appertainment in 4 categories: -Required: If this list has items in it, the directive requires at least 1 of these be present. -AllowedExclusive: Items on this list are all allowed, but only 1 from the list may be here (That is, they are exclusive of eachother). -AllowedOnce: Items on this list are all allowed, but may not be duplicated. Allowed: Items on this list are allowed. Note th at the actual list of 'allowed' is all 4 of these lists together. This is a draft patch to swtich Clang over to use those tables. Surgery to get this to happen in Clang Sema was somewhat reasonable. However, some gaps in the implementations are obvious, the existing clang implementation disagrees with the Flang interpretation of it. SO, we're keeping a task list here based on what gets discovered. Changes to Clang: - [x] Switch 'directive-kind' enum conversions to use tablegen See ff1a7bd - [x] Switch 'clause-kind' enum conversions to use tablegen See ff1a7bd - [x] Investigate 'parse' test differences to see if any new disagreements arise. - [x] Clang/Flang disagree as to whether 'collapse' can be multiple times on a loop. Further research showed no prose to limit this, and the comment on the clang implementation said "no good reason to allow", so no standards justification. - [x] Clang/Flang disagree whether 'num_gangs' can appear >1 on a compute/combined construct. This ended up being an unjustified restriction. - [x] Clang/Flang disagree as to the list of required clauses on a 'set' construct. My research shows that Clang mistakenly included 'if' in the list, and that it should be just 'default_async', 'device_num', and 'device_type'. - [x] Order of 'at least one of' diagnostic has changed. Tests were updated. - [x] Ensure we are properly 'de-aliasing' clause names in appertainment checks? - [x] What is 'shortloop'? 'shortloop' seems to be an old non-standard extension that isn't supported by flang, but is parsed for backward compat reasons. Clang won't parse, but we at least have a spot for it in the clause list. - [x] Implemented proposed change for 'routine' gang/worker/vector/seq. (see issue 539) - [x] Implement init/shutdown can only have 1 'if' (see issue 540) - [x] Clang/Flang disagree as to whether 'tile' is permitted more than once on a 'loop' or combined constructs (Flang prohibits >1). I see no justification for this in the standard. EDIT: I found a comment in clang that I did this to make SOMETHING around duplicate checks easier. Discussion showed we should actually have a better behavior around 'device_type' and duplicates, so I've since implemented that. - [x] Clang/Flang disagree whether 'gang', 'worker', or 'vector' may appear on the same construct as a 'seq' on a 'loop' or 'combined'. There is prose for this in 2022: (a gang, worker, or vector clause may not appear if a 'seq' clause appears). EDIT: These don't actually disagree, but aren't in the .td file, so I restored the existing code to do this. - [x] Clang/Flang disagree on whether 'bind' can appear >1 on a 'routine'. I believe line 3096 (A bind clause may not bind to a routine name that has a visible bind clause) makes this limitation (Flang permits >1 bind). we discussed and decided this should have the same rules as worker/vector/etc, except without the 'exactly 1 of' rule (so no dupes in individual sections). - [x] Clang/Flang disagree on whether 'init'/'shutdown' can have multiple 'device_num' clauses. I believe there is no supporting prose for this limitation., We decided that `device_num` should only happen 1x. - [x] Clang/Flang disagree whether 'num_gangs' can appear >1 on a 'kernels' construct. Line 1173 (On a kernels construct, the num_gangs clause must have a single argument) justifies limiting on a per-arguement basis, but doesn't do so for multiple num_gangs clauses. WE decided to do this with the '1-per-device-type' region for num_gangs, num_workers, and vector_length, see openacc bug here: https://github.com/OpenACC/openacc-spec/issues/541 Changes to Flang: - [x] Clang/Flang disgree on whether 'atomic' can take an 'if' clause. This was added in OpenACC3.3_Next See llvm#135451 - [x] Clang/Flang disagree on whether 'finalize' can be allowed >1 times on a 'exit_data' construct. see llvm#135415. - [x] Clang/Flang disagree whether 'if_present' should be allowed >1 times on a 'host_data'/'update' construct. see llvm#135422 - [x] Clang/Flang disagree on whether 'init'/'shutdown' can have multiple 'device_type' clauses. I believe there is no supporting prose for this limitation. - [ ] SEE change for num_gangs/etc above. Changes that need discussion/research:
llvm#135372) …uses The Flang implemenation of OpenACC uses a .td file in the llvm/Frontend directory to determine appertainment in 4 categories: -Required: If this list has items in it, the directive requires at least 1 of these be present. -AllowedExclusive: Items on this list are all allowed, but only 1 from the list may be here (That is, they are exclusive of eachother). -AllowedOnce: Items on this list are all allowed, but may not be duplicated. Allowed: Items on this list are allowed. Note th at the actual list of 'allowed' is all 4 of these lists together. This is a draft patch to swtich Clang over to use those tables. Surgery to get this to happen in Clang Sema was somewhat reasonable. However, some gaps in the implementations are obvious, the existing clang implementation disagrees with the Flang interpretation of it. SO, we're keeping a task list here based on what gets discovered. Changes to Clang: - [x] Switch 'directive-kind' enum conversions to use tablegen See ff1a7bd - [x] Switch 'clause-kind' enum conversions to use tablegen See ff1a7bd - [x] Investigate 'parse' test differences to see if any new disagreements arise. - [x] Clang/Flang disagree as to whether 'collapse' can be multiple times on a loop. Further research showed no prose to limit this, and the comment on the clang implementation said "no good reason to allow", so no standards justification. - [x] Clang/Flang disagree whether 'num_gangs' can appear >1 on a compute/combined construct. This ended up being an unjustified restriction. - [x] Clang/Flang disagree as to the list of required clauses on a 'set' construct. My research shows that Clang mistakenly included 'if' in the list, and that it should be just 'default_async', 'device_num', and 'device_type'. - [x] Order of 'at least one of' diagnostic has changed. Tests were updated. - [x] Ensure we are properly 'de-aliasing' clause names in appertainment checks? - [x] What is 'shortloop'? 'shortloop' seems to be an old non-standard extension that isn't supported by flang, but is parsed for backward compat reasons. Clang won't parse, but we at least have a spot for it in the clause list. - [x] Implemented proposed change for 'routine' gang/worker/vector/seq. (see issue 539) - [x] Implement init/shutdown can only have 1 'if' (see issue 540) - [x] Clang/Flang disagree as to whether 'tile' is permitted more than once on a 'loop' or combined constructs (Flang prohibits >1). I see no justification for this in the standard. EDIT: I found a comment in clang that I did this to make SOMETHING around duplicate checks easier. Discussion showed we should actually have a better behavior around 'device_type' and duplicates, so I've since implemented that. - [x] Clang/Flang disagree whether 'gang', 'worker', or 'vector' may appear on the same construct as a 'seq' on a 'loop' or 'combined'. There is prose for this in 2022: (a gang, worker, or vector clause may not appear if a 'seq' clause appears). EDIT: These don't actually disagree, but aren't in the .td file, so I restored the existing code to do this. - [x] Clang/Flang disagree on whether 'bind' can appear >1 on a 'routine'. I believe line 3096 (A bind clause may not bind to a routine name that has a visible bind clause) makes this limitation (Flang permits >1 bind). we discussed and decided this should have the same rules as worker/vector/etc, except without the 'exactly 1 of' rule (so no dupes in individual sections). - [x] Clang/Flang disagree on whether 'init'/'shutdown' can have multiple 'device_num' clauses. I believe there is no supporting prose for this limitation., We decided that `device_num` should only happen 1x. - [x] Clang/Flang disagree whether 'num_gangs' can appear >1 on a 'kernels' construct. Line 1173 (On a kernels construct, the num_gangs clause must have a single argument) justifies limiting on a per-arguement basis, but doesn't do so for multiple num_gangs clauses. WE decided to do this with the '1-per-device-type' region for num_gangs, num_workers, and vector_length, see openacc bug here: https://github.com/OpenACC/openacc-spec/issues/541 Changes to Flang: - [x] Clang/Flang disgree on whether 'atomic' can take an 'if' clause. This was added in OpenACC3.3_Next See llvm#135451 - [x] Clang/Flang disagree on whether 'finalize' can be allowed >1 times on a 'exit_data' construct. see llvm#135415. - [x] Clang/Flang disagree whether 'if_present' should be allowed >1 times on a 'host_data'/'update' construct. see llvm#135422 - [x] Clang/Flang disagree on whether 'init'/'shutdown' can have multiple 'device_type' clauses. I believe there is no supporting prose for this limitation. - [ ] SEE change for num_gangs/etc above. Changes that need discussion/research:
llvm#135372) …uses The Flang implemenation of OpenACC uses a .td file in the llvm/Frontend directory to determine appertainment in 4 categories: -Required: If this list has items in it, the directive requires at least 1 of these be present. -AllowedExclusive: Items on this list are all allowed, but only 1 from the list may be here (That is, they are exclusive of eachother). -AllowedOnce: Items on this list are all allowed, but may not be duplicated. Allowed: Items on this list are allowed. Note th at the actual list of 'allowed' is all 4 of these lists together. This is a draft patch to swtich Clang over to use those tables. Surgery to get this to happen in Clang Sema was somewhat reasonable. However, some gaps in the implementations are obvious, the existing clang implementation disagrees with the Flang interpretation of it. SO, we're keeping a task list here based on what gets discovered. Changes to Clang: - [x] Switch 'directive-kind' enum conversions to use tablegen See ff1a7bd - [x] Switch 'clause-kind' enum conversions to use tablegen See ff1a7bd - [x] Investigate 'parse' test differences to see if any new disagreements arise. - [x] Clang/Flang disagree as to whether 'collapse' can be multiple times on a loop. Further research showed no prose to limit this, and the comment on the clang implementation said "no good reason to allow", so no standards justification. - [x] Clang/Flang disagree whether 'num_gangs' can appear >1 on a compute/combined construct. This ended up being an unjustified restriction. - [x] Clang/Flang disagree as to the list of required clauses on a 'set' construct. My research shows that Clang mistakenly included 'if' in the list, and that it should be just 'default_async', 'device_num', and 'device_type'. - [x] Order of 'at least one of' diagnostic has changed. Tests were updated. - [x] Ensure we are properly 'de-aliasing' clause names in appertainment checks? - [x] What is 'shortloop'? 'shortloop' seems to be an old non-standard extension that isn't supported by flang, but is parsed for backward compat reasons. Clang won't parse, but we at least have a spot for it in the clause list. - [x] Implemented proposed change for 'routine' gang/worker/vector/seq. (see issue 539) - [x] Implement init/shutdown can only have 1 'if' (see issue 540) - [x] Clang/Flang disagree as to whether 'tile' is permitted more than once on a 'loop' or combined constructs (Flang prohibits >1). I see no justification for this in the standard. EDIT: I found a comment in clang that I did this to make SOMETHING around duplicate checks easier. Discussion showed we should actually have a better behavior around 'device_type' and duplicates, so I've since implemented that. - [x] Clang/Flang disagree whether 'gang', 'worker', or 'vector' may appear on the same construct as a 'seq' on a 'loop' or 'combined'. There is prose for this in 2022: (a gang, worker, or vector clause may not appear if a 'seq' clause appears). EDIT: These don't actually disagree, but aren't in the .td file, so I restored the existing code to do this. - [x] Clang/Flang disagree on whether 'bind' can appear >1 on a 'routine'. I believe line 3096 (A bind clause may not bind to a routine name that has a visible bind clause) makes this limitation (Flang permits >1 bind). we discussed and decided this should have the same rules as worker/vector/etc, except without the 'exactly 1 of' rule (so no dupes in individual sections). - [x] Clang/Flang disagree on whether 'init'/'shutdown' can have multiple 'device_num' clauses. I believe there is no supporting prose for this limitation., We decided that `device_num` should only happen 1x. - [x] Clang/Flang disagree whether 'num_gangs' can appear >1 on a 'kernels' construct. Line 1173 (On a kernels construct, the num_gangs clause must have a single argument) justifies limiting on a per-arguement basis, but doesn't do so for multiple num_gangs clauses. WE decided to do this with the '1-per-device-type' region for num_gangs, num_workers, and vector_length, see openacc bug here: https://github.com/OpenACC/openacc-spec/issues/541 Changes to Flang: - [x] Clang/Flang disgree on whether 'atomic' can take an 'if' clause. This was added in OpenACC3.3_Next See llvm#135451 - [x] Clang/Flang disagree on whether 'finalize' can be allowed >1 times on a 'exit_data' construct. see llvm#135415. - [x] Clang/Flang disagree whether 'if_present' should be allowed >1 times on a 'host_data'/'update' construct. see llvm#135422 - [x] Clang/Flang disagree on whether 'init'/'shutdown' can have multiple 'device_type' clauses. I believe there is no supporting prose for this limitation. - [ ] SEE change for num_gangs/etc above. Changes that need discussion/research:
The new version of the OpenACC specification will allow the if clause on the atomic directives. Allow it in
ACC.td
and update the parse node and parser in flang to support it.OpenACC dialect will need to be updated to support it as well.