[Bug c++/90078] [7/8/9 Regression] ICE with deep templates caused by overflow [PATCH]

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to bin cheng from comment #4)
> In get_scaled_computation_cost_at, we have very big ratio between
> bb_count/loop_count:
> 
> (gdb) p data->current_loop->latch->count                   
> $50 = {static n_bits = 61, static max_count = 2305843009213693950, static
> uninitialized_count = 2305843009213693951, m_val = 158483, m_quality =
> profile_guessed_local}
> (gdb) p gimple_bb(at)->count
> $51 = {static n_bits = 61, static max_count = 2305843009213693950, static
> uninitialized_count = 2305843009213693951, m_val = 1569139790, m_quality =
> profile_guessed_local}
> (gdb) p 1569139790 / 158483
> $52 = 9900
> (gdb) p cost
> $53 = {cost = 20, complexity = 2, scratch = 1}
> (gdb) p 19 * 9900
> $54 = 188100
> 
> as a result, sum_cost soon reaches to overflow of infinite_cost.  Shall we
> cap the ratio so that it doesn't grow too quick?  Of course, some benchmark
> data is needed for this heuristic tuning.

I would implement the capping in comp_cost struct where each individual
operator
can cap to infinite. What do you think Bin?

> 
> 
> Another problem is the generated binary has segment fault issue even
> compiled O0:
> 
> $ ./g++ -O0 pr90078.cc -o a.out -ftemplate-depth=1000000 -ftime-report  -g
> -std=c++14
> $ gdb --args ./a.out
> 
> Dump of assembler code for function main():
>    0x0000000000400572 <+0>:     push   %rbp
>    0x0000000000400573 <+1>:     mov    %rsp,%rbp
>    0x0000000000400576 <+4>:     sub    $0x2625a020,%rsp
>    0x000000000040057d <+11>:    lea    -0x2625a020(%rbp),%rax
>    0x0000000000400584 <+18>:    mov    %rax,%rdi
> => 0x0000000000400587 <+21>:    callq  0x4006c0 <Tensor4<float, 100, 100,
> 100, 100>::Tensor4()>
>    0x000000000040058c <+26>:    lea    -0x4c4b410(%rbp),%rax
>    0x0000000000400593 <+33>:    lea    -0xe4e1c10(%rbp),%rdx
> 
> The segment fault happens at the callq instruction.

Yes, same happens also for clang. It's a stack overflow:

$ g++ pr90078.cpp  -ftemplate-depth=1111111 -fsanitize=address && ./a.out 
AddressSanitizer:DEADLYSIGNAL
=================================================================
==5750==ERROR: AddressSanitizer: stack-overflow on address 0x7fffd9da3af0 (pc
0x0000004011cb bp 0x7fffffffdc60 sp 0x7fffd9da3af0 T0)
    #0 0x4011ca in main (/home/marxin/Programming/testcases/a.out+0x4011ca)
    #1 0x7ffff6d32b7a in __libc_start_main ../csu/libc-start.c:308
    #2 0x401109 in _start (/home/marxin/Programming/testcases/a.out+0x401109)

SUMMARY: AddressSanitizer: stack-overflow
(/home/marxin/Programming/testcases/a.out+0x4011ca) in main
==5750==ABORTING