https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83920
--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to cesar from comment #0)
> I think there
> might be other PTX JIT bugs lurking here, because the test program still
> works as intended.
I can make it fail on trunk, by changing the workaround to initialize with one
instead of zero:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 86fc13f4fc0..ab03f3b5fe7 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -4097,7 +4097,7 @@ nvptx_single (unsigned mask, basic_block from,
basic_block to)
There is nothing in the PTX spec to suggest that this is wrong, or
to explain why the extra initialization is needed. So, we
classify
it as a JIT bug, and the extra initialization as workaround. */
- emit_insn_before (gen_movbi (pvar, const0_rtx),
+ emit_insn_before (gen_movbi (pvar, constm1_rtx),
bb_first_real_insn (from));
#endif
emit_insn_before (nvptx_gen_vcast (pvar), tail);
...
[ Note that there are no regressions with this patch, so the test-case triggers
something not present in the current trunk test set. ]
Likewise, reversing the if-then-else order in gemm.f90 makes the testcase fail
on trunk without this patch.
So, this has nothing to do with PTX JIT bugs.
