-
Notifications
You must be signed in to change notification settings - Fork 10
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
Ensure :VAR_MAP and :FUNC_MAP are output in order #29
Conversation
Before, only if there is an '.extern', is_decl is set and only then the variable/function is added to 'decls'. However, global variables/functions may not have .extern - even if they show up with :VAR_MAP and :FUNC_MAP. GCC's mkoffload uses the latter and requires that the order matches the original order. As the output is done as: write_stmts (out, rev_stmts (decls)); htab_traverse (symbol_table, traverse, (void *)out); write_stmts (out, rev_stmts (fns)); it might have happen that :VAR_MAP/:FUNC_MAP lines will be output in hash-map order, which can cause the wrong order. https://gcc.gnu.org/PR100059 * nvptx-as.c (parse_file): Set is_decl when there is a :VAR_MAP or :FUNC_MAP.
Testcase is: int i = 0, a[3];
void update () {
i = 5; a[0] = 42; a[1] = 43; a[2] = 44;
}
#pragma omp declare target link(i,a)
#pragma omp declare target to(update)
int main () {
#pragma omp target map(from: i, a)
update();
__builtin_printf("%d, %d, %d, %d\n", i,a[0],a[1],a[2]);
return 0;
}
By inserting comment outputs before the Once this patch is in, the longer example at https://gcc.gnu.org/bugzilla/attachment.cgi?id=50578 (https://gcc.gnu.org/PR100059) should be committed to GCC. Side question: Why did it not show up before? |
Reproduced both the without and with patch behaviour. |
Thomas, ping. |
Another example for this is https://github.com/clang-ykt/omptests 's t-same-name-definitions which has the same issue + is fixed by the pull request. |
@tschwinge — Ping² |
@tschwinge — Ping^3 |
#29] ... documenting (differently) buggy 'as' behavior re commit 1b5946d, commit 26095fd "Ensure :VAR_MAP and :FUNC_MAP are output in order": GCC/nvptx offloading via x86_64-linux-gnu vs. powerpc64le-linux-gnu host emit slightly different nvptx code, which, for example, in 'test/as/order-2-x86_64-linux-gnu.o' vs. 'test/as/order-2-powerpc64le-linux-gnu.o', now loses an initializer: @@ -8,4 +8,6 @@ //:FUNC_MAP "main$_omp_fn$0" //:VAR_MAP "data" +// BEGIN GLOBAL VAR DEF: data +.visible .global .align 4 .u32 data[1] = // BEGIN GLOBAL FUNCTION DECL: gomp_nvptx_main .extern .func gomp_nvptx_main (.param .u64 %in_ar1, .param .u64 %in_ar2); @@ -14,7 +16,4 @@ // BEGIN GLOBAL VAR DECL: __nvptx_uni .extern .shared .u32 __nvptx_uni[32]; -// BEGIN GLOBAL VAR DEF: data -.visible .global .align 4 .u32 data[1] = -{5 }; // END PREAMBLE .visible .entry main$_omp_fn$0 (.param .u64 %arg, .param .u64 %stack, .param .u64 %sz) ..., and thus: [...] ptxas /tmp/ccFhz3dP.o, line 12; fatal : Parsing error near '.extern': syntax error ptxas fatal : Ptx assembly aborted due to errors nvptx-as: ptxas returned 255 exit status nvptx mkoffload: fatal error: [...]/powerpc64le-unknown-linux-gnu-accel-nvptx-none-gcc returned 1 exit status [...]
Fix the 'as' issue described in commit 3f67564 "Ensure :VAR_MAP and :FUNC_MAP are output in order: add more test cases [#29]" by handling '//:VAR_MAP', '//:FUNC_MAP' as stand-alone directives instead of 'V_comment | V_prefix_comment'. This also happens to unify the x86_64-linux-gnu, powerpc64le-linux-gnu 'test/as/order-1-{x86_64-linux-gnu,powerpc64le-linux-gnu}.o' as well as 'test/as/order-2-{x86_64-linux-gnu,powerpc64le-linux-gnu}.o' files.
Similar to #29 for `:VAR_MAP` and `:FUNC_MAP` (cf. https://gcc.gnu.org/PR100059), nvptx-as must keep the order the same for the entries of newly added indirect-function map table, for which the new tag `:IND_FUNC_MAP` is used. **Cross ref:** https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635176.html
Before, only if there is an '.extern', is_decl is set and only
then the variable/function is added to 'decls'. However, global
variables/functions may not have .extern - even if they show up
with :VAR_MAP and :FUNC_MAP. GCC's mkoffload uses the latter and
requires that the order matches the original order.
As the output is done as:
it might have happen that :VAR_MAP/:FUNC_MAP lines will be output
in hash-map order, which can cause the wrong order.
https://gcc.gnu.org/PR100059