https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79132
Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> --- This is one of the warnings I reported in bug 79052 but hadn't investigated. With your test case I see the out of bounds alloca in the dump so it looks like a true positive to me: $ gcc -O2 -S -Wall -fsanitize=address -fdump-tree-optimized=/dev/stdout b.C | grep __builtin_alloca b.C: In function ‘void rewrite_expr_tree_parallel()’: b.C:25:12: warning: ‘stmt’ is used uninitialized in this function [-Wuninitialized] stmts[1] = stmt; ~~~~~~~~~^~~~~~ stmts_27 = __builtin_alloca (18446744073709551615); stmts_13 = __builtin_alloca (_45); b.C:24:52: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] int **stmts = (int **) __builtin_alloca (stmt_num); ^ b.C:24:52: note: in a call to built-in allocation function ‘void* __builtin_alloca(long unsigned int)’ It seems that -fsanitize=address inserting the test for zero causes jump threading to insert the alloca call with the out-of-bounds constant. IMO, the warning is helpful here because it suggests a potential bug. If the vector argument cannot be empty then adding a precondition/assertion to make it clear both to the compiler and to the reader seems like the right solution. (IIRC, we have seen this same thing before with -sanitize=undefined and the initial implementation of -Wnonnull.) Besides adding the assertion, since op_num is the result of vec::length() which returns unsigned int I wonder if the type of the variable (and all the others that cannot be negative) should also be changed to unsigned.