[Bug sanitizer/60557] UBSAN: ICE after ubsan_expand_null_ifn

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 32380
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32380action=edit
gcc49-pr60557.patch

This should hopefully fix it.

[Bug sanitizer/60557] UBSAN: ICE after ubsan_expand_null_ifn

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557

--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
 This should hopefully fix it.

Looks good to me. For the testcase of comment 1, it also gives the expected
run-time diagnostic:

test.f90:19: runtime error: signed integer overflow: 809078955 * 65539 cannot
be represented in type 'integer(kind=4)'

[Bug sanitizer/60557] UBSAN: ICE after ubsan_expand_null_ifn

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557

--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Tue Mar 18 15:05:30 2014
New Revision: 208652

URL: http://gcc.gnu.org/viewcvs?rev=208652root=gccview=rev
Log:
PR sanitizer/60557
* ubsan.c (ubsan_instrument_unreachable): Call
initialize_sanitizer_builtins.
(ubsan_pass): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ubsan.c

[Bug sanitizer/60557] UBSAN: ICE after ubsan_expand_null_ifn

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
Fixed.

[Bug sanitizer/60557] UBSAN: ICE after ubsan_expand_null_ifn

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org ---
Created attachment 32379
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32379action=edit
Testcase (test.f90)

[Bug sanitizer/60557] UBSAN: ICE after ubsan_expand_null_ifn

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557

--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org ---
And compiling with just -fsanitize=signed-integer-overflow leads to another
ICE:

0x6a0828 contains_struct_check
../../gcc/tree.h:2822
0x6a0828 build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
../../gcc/builtins.c:11259
0x6a1bf7 build_call_expr_loc(unsigned int, tree_node*, int, ...)
../../gcc/builtins.c:11292
0x889199 ubsan_expand_si_overflow_mul_check(gimple_statement_base*)
../../gcc/internal-fn.c:768

[Bug sanitizer/60557] UBSAN: ICE after ubsan_expand_null_ifn

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-17
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Confirmed. Debugging with lldb gives

* thread #1: tid = 0x1c9cf56, 0x0001005c3ba4
f951`gimple_build_call(fn=0x, nargs=2) + 36 at gimple.c:249,
queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
address=0x0)
frame #0: 0x0001005c3ba4 f951`gimple_build_call(fn=0x,
nargs=2) + 36 at gimple.c:249
   246   gimple call;
   247   unsigned i;
   248 
- 249   gcc_assert (TREE_CODE (fn) == FUNCTION_DECL || is_gimple_call_addr
(fn));
   250 
   251   call = gimple_build_call_1 (fn, nargs);
   252 
(lldb) bt
* thread #1: tid = 0x1c9cf56, 0x0001005c3ba4
f951`gimple_build_call(fn=0x, nargs=2) + 36 at gimple.c:249,
queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
address=0x0)
  * frame #0: 0x0001005c3ba4 f951`gimple_build_call(fn=0x,
nargs=2) + 36 at gimple.c:249
frame #1: 0x000100888bdf
f951`ubsan_expand_null_ifn(gsi=gimple_stmt_iterator at 0x7fff5fbff280) +
447 at ubsan.c:590
frame #2: 0x00010087b110 f951`execute(this=unavailable) + 304 at
asan.c:2587

I get a similar ICE for this simpler test

DO i=1,10
END DO
END

However the backtrace is different

* thread #1: tid = 0x1c9cb1a, 0x0001003c03e1
f951`build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
[inlined] contains_struct_check(__g=unavailable, __l=0, __f=unavailable,
__s=TS_BASE, __t=0x) at tree.h:2822, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x0001003c03e1 f951`build_call_expr_loc_array(unsigned int,
tree_node*, int, tree_node**) [inlined]
contains_struct_check(__g=unavailable, __l=0, __f=unavailable, __s=TS_BASE,
__t=0x) at tree.h:2822
   2819contains_struct_check (tree __t, const enum tree_node_structure_enum
__s,
   2820   const char *__f, int __l, const char *__g)
   2821{
- 2822  if (tree_contains_struct[TREE_CODE (__t)][__s] != 1)
   2823  tree_contains_struct_check_failed (__t, __s, __f, __l, __g);
   2824  return __t;
   2825}
(lldb) bt
* thread #1: tid = 0x1c9cb1a, 0x0001003c03e1
f951`build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
[inlined] contains_struct_check(__g=unavailable, __l=0, __f=unavailable,
__s=TS_BASE, __t=0x) at tree.h:2822, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0001003c03e1 f951`build_call_expr_loc_array(unsigned int,
tree_node*, int, tree_node**) [inlined]
contains_struct_check(__g=unavailable, __l=0, __f=unavailable, __s=TS_BASE,
__t=0x) at tree.h:2822
frame #1: 0x0001003c03e1 f951`build_call_expr_loc_array(loc=2147483651,
fndecl=0x, n=3, argarray=0x7fff5fbfefc0) + 17
frame #2: 0x0001003c199c f951`build_call_expr_loc(loc=unavailable,
fndecl=unavailable, n=unavailable) + 172 at builtins.c:11292
frame #3: 0x000100676e5a
f951`ubsan_expand_si_overflow_addsub_check(code=PLUS_EXPR,
stmt=0x000142d49688) + 794 at internal-fn.c:297
frame #4: 0x0001003fdc63
f951`expand_gimple_stmt(stmt=0x000142d49688) + 4083 at cfgexpand.c:2190
frame #5: 0x0001003ff408
f951`expand_gimple_basic_block(bb=unavailable,
disable_tail_calls=unavailable) + 2776 at cfgexpand.c:5152
frame #6: 0x000100400f37 f951`execute + 2345 at cfgexpand.c:5731
frame #7: 0x00010040060e f951`execute(this=unavailable) + 14
frame #8: 0x00010079a78a f951`execute_one_pass(pass=0x000141e127c0)
+ 986 at passes.c:2229
frame #9: 0x00010079aa9e
f951`execute_pass_list(pass=0x000141e127c0) + 30 at passes.c:2282
frame #10: 0x000100425f6b f951`expand_function(node=0x000142c09e18)
+ 235 at cgraphunit.c:1774
frame #11: 0x0001004287ad f951`compile() + 3341 at cgraphunit.c:2006
frame #12: 0x000100428be6 f951`finalize_compilation_unit() + 102 at
cgraphunit.c:2329
frame #13: 0x0001006f5f0e f951`write_global_declarations() + 222 at
langhooks.c:323
frame #14: 0x0001008665a7 f951`compile_file + 167 at toplev.c:562
frame #15: 0x000100868a44 f951`toplev_main(argc=3,
argv=0x7fff5fbff4a0) + 3284 at toplev.c:1914

I have seen several ICEs with different fortran tests, but a few passed, e.g.,

[Book15] f90/bug% cat prec.f90
integer,parameter :: k = selected_real_kind (precision (0.0_8) + 1)
real(kind=k) :: x
x = cos 

[Bug sanitizer/60557] UBSAN: ICE after ubsan_expand_null_ifn

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557

--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The backtrace for the test in comment 0 with -fsanitize=signed-integer-overflow
is the similar to the one I get for the DO loop.