This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/79132] False positive for -Walloc-size-larger-than= with -fsanitize=address aka. bootstrap-asan breakage
- From: "msebor at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 18 Jan 2017 18:58:10 +0000
- Subject: [Bug bootstrap/79132] False positive for -Walloc-size-larger-than= with -fsanitize=address aka. bootstrap-asan breakage
- Auto-submitted: auto-generated
- References: <bug-79132-4@http.gcc.gnu.org/bugzilla/>
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.