[Bug target/80547] New: [6/7/8 Regression] nvptx back end ICE with OpenACC "reduction(OP:x)", "x = [...]"
tschwinge at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Thu Apr 27 14:53:00 GMT 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80547
Bug ID: 80547
Summary: [6/7/8 Regression] nvptx back end ICE with OpenACC
"reduction(OP:x)", "x = [...]"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: openacc
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: cesar at gcc dot gnu.org, jakub at gcc dot gnu.org
Target Milestone: ---
Target: nvptx
Created attachment 41280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41280&action=edit
r.c
As far as I remember, it is permissible to directly write into an
OpenACC/OpenMP reduction variable ("x = [...]", as opposed to modifying it with
some binary operator: "x = x OP [...]"). Looking at the attached test case
(greatly reduced from another test case), that works (and returns the expected
result) for the OpenMP code therein, but runs into a nvptx back end ICE for
OpenACC, if optimizations "-O" are enabled:
Program received signal SIGSEGV, Segmentation fault.
gimplify_assign (dst=0x0, src=0x7ffff6883750, seq_p=0x7fffffffcaf8) at
[...]/gcc/gimplify.c:12779
12779 tree t = build2 (MODIFY_EXPR, TREE_TYPE (dst), dst, src);
(gdb) bt
#0 gimplify_assign (dst=0x0, src=0x7ffff6883750, seq_p=0x7fffffffcaf8) at
[...]/gcc/gimplify.c:12779
#1 0x0000000000d6f384 in nvptx_goacc_reduction_init (call=0x7ffff6957210)
at [...]/gcc/config/nvptx/nvptx.c:5177
#2 nvptx_goacc_reduction (call=0x7ffff6957210) at
[...]/gcc/config/nvptx/nvptx.c:5309
#3 0x000000000090ee56 in execute_oacc_device_lower () at
[...]/gcc/omp-offload.c:1537
#4 (anonymous namespace)::pass_oacc_device_lower::execute (this=<optimized
out>) at [...]/gcc/omp-offload.c:1662
#5 0x00000000009792ad in execute_one_pass (pass=pass@entry=0x16ec8e0) at
[...]/gcc/passes.c:2465
#6 0x0000000000979b78 in execute_pass_list_1 (pass=0x16ec8e0) at
[...]/gcc/passes.c:2554
#7 0x0000000000979bd5 in execute_pass_list (fn=<optimized out>,
pass=<optimized out>) at [...]/gcc/passes.c:2565
#8 0x000000000062f0c7 in cgraph_node::expand
(this=this@entry=0x7ffff6952000) at [...]/gcc/cgraphunit.c:2042
#9 0x0000000000630a4c in expand_all_functions () at
[...]/gcc/cgraphunit.c:2178
#10 symbol_table::compile (this=0x7ffff6888000) at
[...]/gcc/cgraphunit.c:2535
#11 0x0000000000630f36 in symbol_table::compile (this=<optimized out>) at
[...]/gcc/cgraphunit.c:2568
#12 0x000000000058f2b2 in lto_main () at [...]/gcc/lto/lto.c:3334
#13 0x0000000000a4c1af in compile_file () at [...]/gcc/toplev.c:467
#14 0x000000000055ce4f in do_compile () at [...]/gcc/toplev.c:2000
#15 toplev::main (this=this@entry=0x7fffffffcf90, argc=argc@entry=20,
argv=0x16c8b40, argv@entry=0x7fffffffd098) at [...]/gcc/toplev.c:2134
#16 0x000000000055f287 in main (argc=20, argv=0x7fffffffd098) at
[...]/gcc/main.c:39
More information about the Gcc-bugs
mailing list