https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387
Bug ID: 81387
Summary: UBSAN consumes too much memory at -O2
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Created attachment 41712
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41712&action=edit
reproducer
I understand that compiling with UBSAN should require more memory, but in case
of scalar code increase in memory consumption by 50x looks a bit too much.
-O0: 13sec, 0.8Gb
-O2: 5s, 0.4Gb
-O0 -fsanitize=undefined: 100s, 2.7Gb
-O2 -fsanitize=undefined: 255s 42.9Gb
So, it may be useful test case to make sure that memory consumption is
reasonable and not beyond expected limits.
Here is stack when memory consumption goes wild:
#0 bitmap_elt_insert_after(bitmap_head*, bitmap_element*, unsigned int) () at
../../gcc/gcc/bitmap.c:409
#1 0x0000000000a6d7cd in bitmap_set_range (head=head@entry=0x249bac630,
start=start@entry=0, count=<optimized out>) at ../../gcc/gcc/bitmap.c:1233
#2 0x0000000000a6fd3e in bitmap_set_range (head=head@entry=0x249bac630,
start=start@entry=0, count=<optimized out>) at ../../gcc/gcc/bitmap.c:1197
#3 0x0000000000b0b186 in df_mir_alloc(bitmap_head*) () at
../../gcc/gcc/df-problems.c:1913
#4 0x0000000000b05971 in df_analyze_problem (dflow=0xe5f0440,
blocks_to_consider=0x5232ed8, postorder=0x27ebe678, n_blocks=120403) at
../../gcc/gcc/df-core.c:1161
#5 0x0000000000b05a7c in df_analyze_1() () at ../../gcc/gcc/df-core.c:1222
#6 0x00000000015d8cbf in find_and_remove_re () at ../../gcc/gcc/ree.c:1216
#7 rest_of_handle_ree () at ../../gcc/gcc/ree.c:1310
#8 (anonymous namespace)::pass_ree::execute(function*) () at
../../gcc/gcc/ree.c:1338
#9 0x0000000000dce3bb in execute_one_pass(opt_pass*) () at
../../gcc/gcc/passes.c:2492
#10 0x0000000000dcec15 in execute_pass_list_1(opt_pass*) () at
../../gcc/gcc/passes.c:2581
#11 0x0000000000dcec27 in execute_pass_list_1(opt_pass*) () at
../../gcc/gcc/passes.c:2582
#12 0x0000000000dcec27 in execute_pass_list_1(opt_pass*) () at
../../gcc/gcc/passes.c:2582
#13 0x0000000000dcec59 in execute_pass_list(function*, opt_pass*) () at
../../gcc/gcc/passes.c:2592
#14 0x0000000000ae11e0 in cgraph_node::expand() () at
../../gcc/gcc/cgraphunit.c:2052
#15 0x0000000000ae2361 in expand_all_functions () at
../../gcc/gcc/cgraphunit.c:2188
#16 symbol_table::compile() [clone .part.54] () at
../../gcc/gcc/cgraphunit.c:2540
#17 0x0000000000ae4807 in compile (this=0x7fb63a52e100) at
../../gcc/gcc/cgraphunit.c:2632
#18 symbol_table::finalize_compilation_unit (this=0x7fb63a52e100) at
../../gcc/gcc/cgraphunit.c:2629
#19 0x0000000000e9c018 in compile_file () at ../../gcc/gcc/toplev.c:493
#20 0x00000000007ffcb6 in do_compile () at ../../gcc/gcc/toplev.c:2021
#21 toplev::main(int, char**) () at ../../gcc/gcc/toplev.c:2155
#22 0x0000000000801cbb in main (argc=15, argv=0x7ffe16a14d48) at
../../gcc/gcc/main.c:39
I don't mind if this bug is closed as "will not be fixed", but such behaviour
is definitely make using UBSAN problematic on larger code bases, as it may
basically nuke the build system. And I'm not sure if it's UBSAN implementation
is to blame or DF analysis consumes more than it should.
