Compiling the following with g++ -fsanitize=address int main() { int offset=1; char buf[offset]=""; } I get the following: p.C:5:1: internal compiler error: in tree_to_uhwi, at tree.c:7345 } ^ 0xff3be2 tree_to_uhwi(tree_node const*) /home/vitti/gcc7/gcc/tree.c:7345 0xd8005e asan_add_global /home/vitti/gcc7/gcc/asan.c:2268 0xd80a74 add_string_csts(constant_descriptor_tree**, asan_add_string_csts_data*) /home/vitti/gcc7/gcc/asan.c:2478 0xd80fca void hash_table<tree_descriptor_hasher, xcallocator>::traverse_noresize<asan_add_string_csts_data*, &(add_string_csts(constant_descriptor_tree**, asan_add_string_csts_data*))>(asan_add_string_csts_data*) /home/vitti/gcc7/gcc/hash-table.h:950 0xd80fca void hash_table<tree_descriptor_hasher, xcallocator>::traverse<asan_add_string_csts_data*, &(add_string_csts(constant_descriptor_tree**, asan_add_string_csts_data*))>(asan_add_string_csts_data*) /home/vitti/gcc7/gcc/hash-table.h:972 0xd80fca asan_finish_file() /home/vitti/gcc7/gcc/asan.c:2550
Confirmed.
That is a C++ FE bug. If it really wants to support initializing of VLAs (C rejects this), it should do it correctly. Here it creates a STRING_CST with a VLA type, which during expansion is pushed into constant pool. But, ASAN rightly assumes that constant pool objects have constant sizes.
There are problems in this area. See also bug 69487 and bug 58646.
*** Bug 71378 has been marked as a duplicate of this bug. ***
Fixed in 7.1.0