This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug bootstrap/79132] False positive for -Walloc-size-larger-than= with -fsanitize=address aka. bootstrap-asan breakage


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]