Bug 91354 - verify_gimple triggers ICE after reporting 'invalid types in nop conversion' error for avr target
Summary: verify_gimple triggers ICE after reporting 'invalid types in nop conversion' ...
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 10.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: ice-on-valid-code
Depends on:
Reported: 2019-08-05 11:26 UTC by Senthil Kumar Selvaraj
Modified: 2021-12-19 04:24 UTC (History)
1 user (show)

See Also:
Target: avr
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Senthil Kumar Selvaraj 2019-08-05 11:26:32 UTC
For the avr target, compiling the below code causes an 'invalid types in nop conversion' error, followed by a ICE  at 'verify-gimple'

With gdb
(gdb) bt
#0  verify_gimple_assign_unary (stmt=0x7ffff7ae96e0) at /home/saaadhu/code/work/gcc/gcc/tree-cfg.c:3579
#1  0x000000000107ce85 in verify_gimple_assign (stmt=0x7ffff7ae96e0) at /home/saaadhu/code/work/gcc/gcc/tree-cfg.c:4612
#2  0x000000000107dd59 in verify_gimple_stmt (stmt=0x7ffff7ae96e0) at /home/saaadhu/code/work/gcc/gcc/tree-cfg.c:4877
#3  0x000000000107e333 in verify_gimple_in_seq_2 (stmts=0x7ffff7ae9690) at /home/saaadhu/code/work/gcc/gcc/tree-cfg.c:5039
#4  0x000000000107e44b in verify_gimple_in_seq (stmts=0x7ffff7ae9690) at /home/saaadhu/code/work/gcc/gcc/tree-cfg.c:5078
#5  0x0000000000cb72cc in gimplify_body (fndecl=0x7ffff7ad5100, do_parms=true) at /home/saaadhu/code/work/gcc/gcc/gimplify.c:14349
#6  0x0000000000cb77d9 in gimplify_function_tree (fndecl=0x7ffff7ad5100) at /home/saaadhu/code/work/gcc/gcc/gimplify.c:14439
#7  0x0000000000a403ce in cgraph_node::analyze (this=0x7ffff79e62d0) at /home/saaadhu/code/work/gcc/gcc/cgraphunit.c:667
#8  0x0000000000a41dd6 in analyze_functions (first_time=true) at /home/saaadhu/code/work/gcc/gcc/cgraphunit.c:1126
#9  0x0000000000a470a4 in symbol_table::finalize_compilation_unit (this=0x7ffff79e8000) at /home/saaadhu/code/work/gcc/gcc/cgraphunit.c:2840
#10 0x000000000101e43b in compile_file () at /home/saaadhu/code/work/gcc/gcc/toplev.c:481
#11 0x000000000102110b in do_compile () at /home/saaadhu/code/work/gcc/gcc/toplev.c:2190
#12 0x0000000001021421 in toplev::main (this=0x7fffffffe0c6, argc=3, argv=0x7fffffffe1c8) at /home/saaadhu/code/work/gcc/gcc/toplev.c:2325
#13 0x0000000001a92b7c in main (argc=3, argv=0x7fffffffe1c8) at /home/saaadhu/code/work/gcc/gcc/main.c:39

(gdb) call debug_gimple_stmt(stmt)
x = (long unsigned int) p.0_1;

Appears to be a fallout of PR 85450, which changed ptrofftype_p (sizetype) to ptrofftype_p (lhs_type) (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85450#c0). In this case, p.0_1 (pointer to __memx address space) is 24 bits wide, and therefore neither LHS type nor RHS type is ptrofftype_p (sizetype is 16 bits). The code then asserts both LHS and RHS types are of the same kind, which isn't true - one is a pointer and the other is integral. This causes the error and I guess the subsequent ICE. 

$ cat test2.c                             
extern const __memx  int *p;

void foo(void) {
	unsigned long int x;
	x = (unsigned long int) p;

$ ./gcc/cc1 test2.c -mmcu=avr51      
test2.c: In function 'foo':
test2.c:5:6: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
    5 |  x = (unsigned long int) p;
      |      ^

Analyzing compilation unit
test2.c:3:6: error: invalid types in nop conversion
    3 | void foo(void) {
      |      ^~~
long unsigned int
const <address-space-7> int *
x = (long unsigned int) p.0_1;
test2.c:3:6: internal compiler error: 'verify_gimple' failed
0x107e45d verify_gimple_in_seq(gimple*)
0xcb72cb gimplify_body(tree_node*, bool)
0xcb77d8 gimplify_function_tree(tree_node*)
0xa403cd cgraph_node::analyze()
0xa41dd5 analyze_functions
0xa470a3 symbol_table::finalize_compilation_unit()
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Comment 1 Richard Biener 2019-08-05 13:19:55 UTC
I think elsewhere I proposed the "proper" checking involving POINTERS_EXTEND_UNSIGNED and checking for ptr_mode <-> Pmode/word_mode
but that doesn't cover memory address-spaces with different modes
since there we do not know whether to sign- or zero-extend.