* Question about 'gcc/fold-const.c:fold_convert_loc' for 'real_cst' -> 'reference_type' of 'real_type'
@ 2020-12-15 16:02 Thomas Schwinge
2020-12-15 16:07 ` Jakub Jelinek
0 siblings, 1 reply; 2+ messages in thread
From: Thomas Schwinge @ 2020-12-15 16:02 UTC (permalink / raw)
To: gcc
Hi!
In a development branch based on devel/omp/gcc-10 branch (og10), which is
based on releases/gcc-10 branch, I'm running into the following issue.
But: the master branch code seems to look the same.
Given a specific scenario, we run into an ICE:
during GIMPLE pass: oaccdevlow
dump file: o.163t.oaccdevlow1
int_ion_mix_acc.f: In function ‘vtot_ion_mix_._omp_fn.0’:
int_ion_mix_acc.f:50: internal compiler error: in fold_convert_loc, at fold-const.c:2436
50 | !$acc loop reduction(+:eva) independent
|
#0 internal_error (gmsgid=gmsgid@entry=0x17b6308 "in %s, at %s:%d") at [...]/source-gcc/gcc/diagnostic.c:1706
#1 0x00000000005f5c0b in fancy_abort (file=<optimized out>, line=<optimized out>, function=<optimized out>) at [...]/source-gcc/gcc/diagnostic.c:1778
#2 0x000000000080d65e in fold_convert_loc (loc=0, type=0x7ffff6841bd0, arg=0x7ffff685ede0) at [...]/source-gcc/gcc/fold-const.c:2435
#3 0x00000000008cc8c5 in gimplify_modify_expr (expr_p=expr_p@entry=0x7fffffffcc48, pre_p=pre_p@entry=0x7fffffffccb8, post_p=post_p@entry=0x7fffffffca58, want_value=want_value@entry=false) at [...]/source-gcc/gcc/gimplify.c:5741
#4 0x00000000008f7c36 in gimplify_expr (expr_p=expr_p@entry=0x7fffffffcc48, pre_p=pre_p@entry=0x7fffffffccb8, post_p=0x7fffffffca58, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0x8cc0db <is_gimple_stmt(tree)>, fallback=fallback@entry=0) at [...]/source-gcc/gcc/gimplify.c:13921
#5 0x00000000008d1287 in gimplify_stmt (stmt_p=stmt_p@entry=0x7fffffffcc48, seq_p=seq_p@entry=0x7fffffffccb8) at [...]/source-gcc/gcc/gimplify.c:6849
#6 0x00000000008baf79 in gimplify_and_add (t=t@entry=0x7ffff68dda78, seq_p=seq_p@entry=0x7fffffffccb8) at [...]/source-gcc/gcc/gimplify.c:510
#7 0x00000000008fdbb6 in gimplify_assign (dst=0x7ffff68b0048, src=0x7ffff685ede0, seq_p=0x7fffffffccb8) at [...]/source-gcc/gcc/gimplify.c:15533
#8 0x0000000000fc31c1 in nvptx_goacc_reduction_setup (call=call@entry=0x7ffff6880d10, oa=oa@entry=0x7fffffffcd40) at [...]/source-gcc/gcc/config/nvptx/nvptx.c:5791
#9 0x0000000000fc3d4c in nvptx_goacc_reduction (call=0x7ffff6880d10) at [...]/source-gcc/gcc/config/nvptx/nvptx.c:6002
#10 0x0000000000a7c091 in execute_oacc_device_lower () at [...]/source-gcc/gcc/omp-offload.c:2579
#11 0x0000000000a7c9a0 in (anonymous namespace)::pass_oacc_device_lower::execute (this=0x1c3ffb0) at [...]/source-gcc/gcc/omp-offload.c:2862
[...]
(gdb) frame 2
#2 0x000000000080d65e in fold_convert_loc (loc=0, type=0x7ffff6841bd0, arg=0x7ffff685ede0) at [...]/source-gcc/gcc/fold-const.c:2435
2435 gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
(gdb) print arg
$1 = (tree) 0x7ffff685ede0
(gdb) call debug_tree(arg)
<real_cst 0x7ffff685ede0
type <real_type 0x7ffff67b3348 double DF
size <integer_cst 0x7ffff67a3450 constant 64>
unit-size <integer_cst 0x7ffff67a3468 constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set 7 canonical-type 0x7ffff67b3348 precision:64
pointer_to_this <pointer_type 0x7ffff67b3738> reference_to_this <reference_type 0x7ffff6841bd0>>
constant 0.0>
(gdb) print type
$2 = (tree) 0x7ffff6841bd0
(gdb) call debug_tree(type)
<reference_type 0x7ffff6841bd0
type <real_type 0x7ffff67b3348 double DF
size <integer_cst 0x7ffff67a3450 constant 64>
unit-size <integer_cst 0x7ffff67a3468 constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set 7 canonical-type 0x7ffff67b3348 precision:64
pointer_to_this <pointer_type 0x7ffff67b3738> reference_to_this <reference_type 0x7ffff6841bd0>>
public unsigned DI size <integer_cst 0x7ffff67a3450 64> unit-size <integer_cst 0x7ffff67a3468 8>
align:64 warn_if_not_align:0 symtab:0 alias-set 6 structural-equality
pointer_to_this <pointer_type 0x7ffff6841d20>>
Per the 'fold_convert_loc' code (cited below), we see that for 'type' of
'case INTEGER_TYPE' etc. -- which 'type' of 'case REFERENCE_TYPE' does
"fall through" into -- we do not handle 'arg' of 'REAL_CST' like we do
for 'type' of 'case REAL_TYPE'.
Now, as this code has been like that "forever", I have difficulties to
imagine that this may be a bug. Is this wrong usage of
'fold_convert_loc'? (What does it mean to convert a 'real_cst' into a
'reference_type' of 'real_type'?) (... translating to: something is
going wrong elsewhere, in OpenACC 'reductions' handling?)
'gcc/fold-const.c':
2392 /* Convert expression ARG to type TYPE. Used by the middle-end for
2393 simple conversions in preference to calling the front-end's convert. */
2394
2395 tree
2396 fold_convert_loc (location_t loc, tree type, tree arg)
2397 {
2398 tree orig = TREE_TYPE (arg);
2399 tree tem;
2400
2401 if (type == orig)
2402 return arg;
2403
2404 if (TREE_CODE (arg) == ERROR_MARK
2405 || TREE_CODE (type) == ERROR_MARK
2406 || TREE_CODE (orig) == ERROR_MARK)
2407 return error_mark_node;
2408
2409 switch (TREE_CODE (type))
2410 {
2411 case POINTER_TYPE:
2412 case REFERENCE_TYPE:
2413 /* Handle conversions between pointers to different address spaces. */
2414 if (POINTER_TYPE_P (orig)
2415 && (TYPE_ADDR_SPACE (TREE_TYPE (type))
2416 != TYPE_ADDR_SPACE (TREE_TYPE (orig))))
2417 return fold_build1_loc (loc, ADDR_SPACE_CONVERT_EXPR, type, arg);
2418 /* fall through */
2419
2420 case INTEGER_TYPE: case ENUMERAL_TYPE: case BOOLEAN_TYPE:
2421 case OFFSET_TYPE:
2422 if (TREE_CODE (arg) == INTEGER_CST)
2423 {
2424 tem = fold_convert_const (NOP_EXPR, type, arg);
2425 if (tem != NULL_TREE)
2426 return tem;
2427 }
2428 if (INTEGRAL_TYPE_P (orig) || POINTER_TYPE_P (orig)
2429 || TREE_CODE (orig) == OFFSET_TYPE)
2430 return fold_build1_loc (loc, NOP_EXPR, type, arg);
2431 if (TREE_CODE (orig) == COMPLEX_TYPE)
2432 return fold_convert_loc (loc, type,
2433 fold_build1_loc (loc, REALPART_EXPR,
2434 TREE_TYPE (orig), arg));
2435 gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
2436 && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig)));
2437 return fold_build1_loc (loc, VIEW_CONVERT_EXPR, type, arg);
2438
2439 case REAL_TYPE:
2440 if (TREE_CODE (arg) == INTEGER_CST)
2441 {
2442 tem = fold_convert_const (FLOAT_EXPR, type, arg);
2443 if (tem != NULL_TREE)
2444 return tem;
2445 }
2446 else if (TREE_CODE (arg) == REAL_CST)
2447 {
2448 tem = fold_convert_const (NOP_EXPR, type, arg);
2449 if (tem != NULL_TREE)
2450 return tem;
2451 }
2452 else if (TREE_CODE (arg) == FIXED_CST)
2453 {
2454 tem = fold_convert_const (FIXED_CONVERT_EXPR, type, arg);
2455 if (tem != NULL_TREE)
2456 return tem;
2457 }
2458
2459 switch (TREE_CODE (orig))
2460 {
2461 case INTEGER_TYPE:
2462 case BOOLEAN_TYPE: case ENUMERAL_TYPE:
2463 case POINTER_TYPE: case REFERENCE_TYPE:
2464 return fold_build1_loc (loc, FLOAT_EXPR, type, arg);
2465
2466 case REAL_TYPE:
2467 return fold_build1_loc (loc, NOP_EXPR, type, arg);
2468
2469 case FIXED_POINT_TYPE:
2470 return fold_build1_loc (loc, FIXED_CONVERT_EXPR, type, arg);
2471
2472 case COMPLEX_TYPE:
2473 tem = fold_build1_loc (loc, REALPART_EXPR, TREE_TYPE (orig), arg);
2474 return fold_convert_loc (loc, type, tem);
2475
2476 default:
2477 gcc_unreachable ();
2478 }
[...]
Grüße
Thomas
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Question about 'gcc/fold-const.c:fold_convert_loc' for 'real_cst' -> 'reference_type' of 'real_type'
2020-12-15 16:02 Question about 'gcc/fold-const.c:fold_convert_loc' for 'real_cst' -> 'reference_type' of 'real_type' Thomas Schwinge
@ 2020-12-15 16:07 ` Jakub Jelinek
0 siblings, 0 replies; 2+ messages in thread
From: Jakub Jelinek @ 2020-12-15 16:07 UTC (permalink / raw)
To: Thomas Schwinge; +Cc: gcc
On Tue, Dec 15, 2020 at 05:02:24PM +0100, Thomas Schwinge wrote:
> Per the 'fold_convert_loc' code (cited below), we see that for 'type' of
> 'case INTEGER_TYPE' etc. -- which 'type' of 'case REFERENCE_TYPE' does
> "fall through" into -- we do not handle 'arg' of 'REAL_CST' like we do
> for 'type' of 'case REAL_TYPE'.
>
> Now, as this code has been like that "forever", I have difficulties to
> imagine that this may be a bug. Is this wrong usage of
> 'fold_convert_loc'? (What does it mean to convert a 'real_cst' into a
> 'reference_type' of 'real_type'?) (... translating to: something is
> going wrong elsewhere, in OpenACC 'reductions' handling?)
This is definitely not a bug in fold_convert, but in whatever is calling it,
converting something floating to a REFERENCE_TYPE doesn't make any sense.
One usually wants to convert some pointer to reference or another reference
to reference; and as one can't take address of real_cst, one probably
somewhere should have forced the constant into a variable so that its
address could be converted to the reference.
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-12-15 16:08 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-15 16:02 Question about 'gcc/fold-const.c:fold_convert_loc' for 'real_cst' -> 'reference_type' of 'real_type' Thomas Schwinge
2020-12-15 16:07 ` Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).