https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94278
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2020-04-21 00:00:00 |2020-4-22
--- Comment #3 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to Andrew Stubbs from comment #2)
> Well, it works for me:
>
> PASS: libgomp.c/examples-4/async_target-2.c (test for excess errors)
> PASS: libgomp.c/examples-4/async_target-2.c execution test
Strange.
> That's with an unmodified LLVM 9 we built ourselves.
By the way, I see the same problem when using LLVM 10.
Most certainly there is some problem in the LLVM assembler (because that tool
certainly should SIGSEGV even when presented possibly "strange" input), and
maybe that depends on the optimization level that LLVM has been compiled with,
or something like that...
But, I found at least something. From a quick search through my email
archives, I see that there's a huge (maybe even complete?, not verified)
overlap compared to the test FAILs reported in PR81430 "nvptx acceleration
compilation broken because of running pass_partition_blocks". And indeed the
same '-freorder-blocks-and-partition' ('flag_reorder_blocks_and_partition')
nvptx force-disable hack that once got installed in r250421 "Add
nvptx_override_options_after_change" (later reverted after proper fix for that
issue, r250852 "Apply finish_options on DECL_FUNCTION_SPECIFIC_OPTIMIZATION for
ACCEL_COMPILER") also does cure (or rather, avoid?) this problem reported here
for GCN offloading compilation, where assumed-correct GCC GCN code is generated
that the LLVM assembler fails to understand.
Would the following be OK to commit as a workaround? If approving this patch,
please respond with "Reviewed-by: NAME <EMAIL>" so that your effort will be
recorded in the commit log, see <https://gcc.gnu.org/wiki/Reviewed-by>. The
GCN code generated in 'build-gcc-offload-amdgcn-amdhsa/amdgcn-amdhsa/' doesn't
change at all, and it doesn't cause any libgomp offloading compilation
regressions, but I have not yet otherwise assessed whether this breaks
anything.
+static void
+gcn_override_options_after_change (void)
+{
+ flag_reorder_blocks_and_partition = 0;
+}
+#undef TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
+#define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
gcn_override_options_after_change
At the very least, this gives a clue about where to further look for what the
actual problem is.
