https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77606
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The only bug is in the testcase, using __builtin_object_size (, 2) for this is
just wrong, 0 is completely valid return value for that builtin, it is the
"don't know" value that is returned whenever the code doesn't figure it out.
__builtin_object_size (, 0) in this case also returns -1, "don't know" value.
So, if anything, this can be treated as an enhancement request. Right now for
malloc-like calls, including calls with alloc_size argument, we do:
if (arg1 < 0 || arg1 >= (int)gimple_call_num_args (call)
|| TREE_CODE (gimple_call_arg (call, arg1)) != INTEGER_CST
|| (arg2 >= 0
&& (arg2 >= (int)gimple_call_num_args (call)
|| TREE_CODE (gimple_call_arg (call, arg2)) != INTEGER_CST)))
return unknown[object_size_type];
So, the enhancement request would be for gimple_call_arg (call, argN) here
being an SSA_NAME instead of INTEGER_CST to try to prove some range instead
(and for the multiplication case do it with extra care because of possible
overflows).
I have reservations about using get_range_info for that though, the VRP stuff
is computed from many sources, including assumptions that undefined behavior
will not happen etc. But, these builtins are primarily used for security
purposes, and the stuff it is guarding is also undefined behavior, so if
anything, it should do some cheap short walk of the operands and compute range
more conservatively (perhaps only allow SSA_NAME copies, perhaps casts, and
PHIs with all constant arguments or something similar?).
