https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101419
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--- gcc/tree-object-size.c.jj 2021-01-04 10:25:39.911221618 +0100
+++ gcc/tree-object-size.c 2021-07-12 11:28:51.328120222 +0200
@@ -1393,6 +1393,11 @@ pass_object_sizes::execute (function *fu
{
tree tem = make_ssa_name (type);
gimple_call_set_lhs (call, tem);
+ if (object_size_type == 1)
+ {
+ ost = build_zero_cst (TREE_TYPE (ost));
+ gimple_call_set_arg (call, 1, ost);
+ }
enum tree_code code
= object_size_type == 1 ? MIN_EXPR : MAX_EXPR;
tree cst = build_int_cstu (type, bytes);
works, but unfortunately only for __builtin_object_size (, 1).
When I did that also for 3 (to turn it into 2), it breaks several
gcc.dg/builtin-object-size*.c tests.
0 is defined as an upper bound of the object size, subobjects not taken into
account
1 is defined similarly, but subobjects are taken into account
2 is defined as a lower bound of the object size, subobjects not taken into
account
3 is 2 with subobjects
-D_FORTIFY_SOURCE={1,2} typically only uses 0 and 1 modes, 2 and 3 are rare,
and are useful e.g. when somebody wants to find out if the object size is exact
or not (for exact case the upper and lower bounds are equal).
