On 2023-08-01 17:35, Qing Zhao wrote:
typedef struct
{
int a;
} A;
size_t f()
{
A *p = malloc (1);
return __builtin_object_size (p, 0);
Correction, that should be __builtin_object_size (p->a, 0).
Actually, it should be __builtin_object_size(p->a, 1).
For
On 2023-07-21 07:21, Martin Uecker via Gcc-patches wrote:
This patch adds a warning for allocations with insufficient size
based on the "alloc_size" attribute and the type of the pointer
the result is assigned to. While it is theoretically legal to
assign to the wrong pointer type and cast it
On 2023-07-31 14:13, Qing Zhao wrote:
Okay. I see.
Then if the size info from the TYPE is smaller than the size info from the
malloc,
then based on the current code, we use the smaller one between these two,
i.e, the size info from the TYPE. (Even for the OST_MAXIMUM).
Is such behavior
On 2023-07-31 13:03, Siddhesh Poyarekar wrote:
On 2023-07-31 12:47, Qing Zhao wrote:
Hi, Sid and Jakub,
I have a question in the following source portion of the routine
“addr_object_size” of gcc/tree-object-size.cc:
743 bytes = compute_object_offset (TREE_OPERAND (ptr, 0), var
On 2023-07-31 12:47, Qing Zhao wrote:
Hi, Sid and Jakub,
I have a question in the following source portion of the routine
“addr_object_size” of gcc/tree-object-size.cc:
743 bytes = compute_object_offset (TREE_OPERAND (ptr, 0), var);
744 if (bytes != error_mark_node)
745
/object-size-dyn.c (dyn): New parameter RET.
(main): Use it.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/ubsan/object-size-dyn.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/ubsan/object-size-dyn.c
b/gcc/testsuite/gcc.dg/ubsan
On 2023-04-24 12:03, Jakub Jelinek wrote:
On Thu, Apr 20, 2023 at 01:57:55PM -0400, Siddhesh Poyarekar wrote:
Similarly for other functions which have other ranges, perhaps not with so
nice round numbers. Say asin has [-pi/2, pi/2] range, those numbers aren't
exactly representable
On 2023-04-21 02:52, Jakub Jelinek wrote:
On Thu, Apr 20, 2023 at 09:14:10PM -0400, Siddhesh Poyarekar wrote:
On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
For bounds that aren't representable, one could get error bounds from
libm-test-ulps data in glibc, although I reckon those won't
On 2023-04-20 13:57, Siddhesh Poyarekar wrote:
For bounds that aren't representable, one could get error bounds from
libm-test-ulps data in glibc, although I reckon those won't be
exhaustive. From a quick peek at the sin/cos data, the arc target seems
to be among the worst performers at about
On 2023-04-20 11:52, Jakub Jelinek wrote:
Why? Unless an implementation guarantees <= 0.5ulps errors, it can be one
or more ulps off, why is an error at or near 1.0 or -1.0 error any worse
than similar errors for other values?
In a general sense, maybe not, but in the sense of breaching the
On 2023-04-20 10:02, Jakub Jelinek wrote:
On x86_64-linux with glibc 2.35, I see
for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD DOWNWARD
TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o /tmp/sincos{,.c} -lm;
/tmp/sincos || echo $i $j; done; done
Aborted (core dumped)
FLOAT
On 2023-04-20 08:59, Jakub Jelinek via Gcc-patches wrote:
+r.set (type, dconstm1, dconst1);
See above, are we sure we can use [-1., 1.] range safely, or should that be
[-1.-Nulps, 1.+Nulps] for some kind of expected worse error margin of the
implementation? And ditto for -frounding-math,
On 2023-02-17 14:43, Jeff Law wrote:
On 2/17/23 06:41, Siddhesh Poyarekar wrote:
-Wall enables -Wuse-after-free=2 and not -Wuse-after-free=3.
gcc/ChangeLog:
* gcc/doc/invoke.texi (@item -Wall): Fix typo in
-Wuse-after-free.
Looks obvious to me. If you haven't committed it already
-Wall enables -Wuse-after-free=2 and not -Wuse-after-free=3.
gcc/ChangeLog:
* gcc/doc/invoke.texi (@item -Wall): Fix typo in
-Wuse-after-free.
Signed-off-by: Siddhesh Poyarekar
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc
On 2023-02-08 14:09, Joseph Myers wrote:
What must be avoided is -pedantic diagnostics for
struct flex1 { int n; int data[1]; };
struct out_flex_end1 { int m; struct flex1 flex_data; };
regardless of whether considered flexible or not, since that's clearly
valid in standard C.
Are you sure
On 2023-01-25 22:32, Siddhesh Poyarekar wrote:
Instead of using TREE_OPERAND (expr, 2) directly, use
component_ref_field_offset instead, which does scaling for us. The
function also substitutes PLACEHOLDER_EXPRs, which is probably what we
want anyway but I'm not sure if it's relevant
On 2023-02-06 18:14, Joseph Myers wrote:
On Mon, 6 Feb 2023, Qing Zhao via Gcc-patches wrote:
In GCC14:
1. Include this new warning -Wgnu-varaible-sized-type-not-at-end to -Wall
2. Deprecate this extension from GCC. (Or delay this to next release?).
Any deprecation, or inclusion in -Wall,
On 2023-02-02 03:33, Richard Biener wrote:
looking at PR77650 what seems missing there is the semantics of this
extension as expected/required by the glibc use. comment#5 seems
to suggest that for my example above its expected that
Y.x.data[0] aliases Y.end?! There must be a better way to
On 2023-02-01 13:24, Qing Zhao wrote:
On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar wrote:
On 2023-01-31 09:11, Qing Zhao wrote:
Update documentation to clarify a GCC extension on structure with
flexible array member being nested in another structure.
gcc/ChangeLog:
* doc
On 2023-01-31 09:11, Qing Zhao wrote:
Update documentation to clarify a GCC extension on structure with
flexible array member being nested in another structure.
gcc/ChangeLog:
* doc/extend.texi: Document GCC extension on a structure containing
a flexible array member to be a
On 2023-01-31 09:11, Qing Zhao wrote:
GCC extension accepts the case when a struct with a flexible array member
is embedded into another struct (possibly recursively).
__builtin_object_size should treat such struct as flexible size per
-fstrict-flex-arrays.
PR tree-optimization/101832
-4.c: Likewise.
* gcc.dg/builtin-object-size-6.c: Likewise.
* gcc.dg/builtin-object-size-7.c: Likewise.
* gcc.dg/builtin-object-size-8.c: Likewise.
* gcc.dg/pr101836.c: Likewise.
* gcc.dg/strict-flex-array-3.c: Likewise.
Signed-off-by: Siddhesh Poyarekar
On 2023-01-31 07:46, Jakub Jelinek wrote:
On Wed, Dec 21, 2022 at 05:25:54PM -0500, Siddhesh Poyarekar wrote:
The tree object size pass tries to fail when it detects a flex array in
the struct, but it ends up doing the right thing only when the flex
array is in the outermost struct. For nested
also like the comments you added into tree-object-size.cc, making the code
much easier to be understood.
Minor comments below:
On Dec 21, 2022, at 5:25 PM, Siddhesh Poyarekar wrote:
The tree object size pass tries to fail when it detects a flex array in
the struct, but it ends up doing the right
.
(test_dynarray_struct_member_b, test_dynarray_struct_member_c,
test_dynarray_struct_member_d,
test_dynarray_struct_member_subobj_b,
test_dynarray_struct_member_subobj_c,
test_dynarray_struct_member_subobj_d): New tests.
(main): Call them.
Signed-off-by: Siddhesh
On 2023-01-25 02:44, Richard Biener wrote:
t = TREE_OPERAND (expr, 1);
- off = size_binop (PLUS_EXPR, DECL_FIELD_OFFSET (t),
+ off = size_binop (PLUS_EXPR,
+ (TREE_OPERAND (expr, 2) ? TREE_OPERAND (expr, 2)
+: DECL_FIELD_OFFSET
(compute_object_offset): Use
TREE_OPERAND(ref, 2) for COMPONENT_REF when available.
gcc/testsuite/ChangeLog:
PR tree-optimization/108522
* builtin-dynamic-object-size-0.c (test_dynarray_struct_member):
new test.
(main): Call it.
Signed-off-by: Siddhesh Poyarekar
ping!
On 2022-12-21 17:25, Siddhesh Poyarekar wrote:
Hi,
The first patch in the series is just a minor test cleanup that I did to
make sure all tests in a test case run (instead of aborting at first
failure) and print the ones that failed. The second patch is the actual
fix.
The patch
Ping!
On 2022-12-21 17:25, Siddhesh Poyarekar wrote:
Hi,
The first patch in the series is just a minor test cleanup that I did to
make sure all tests in a test case run (instead of aborting at first
failure) and print the ones that failed. The second patch is the actual
fix.
The patch
On 2022-12-27 13:25, Jeff Law wrote:
On 12/15/22 12:25, Siddhesh Poyarekar wrote:
Break the _FORTIFY_SOURCE-specific builtins out into a separate
subsection from Object Size Checking built-ins and mention
_FORTIFY_SOURCE in there so that the link between the object size
checking builtins
Ping!
On 2022-12-21 17:25, Siddhesh Poyarekar wrote:
Hi,
The first patch in the series is just a minor test cleanup that I did to
make sure all tests in a test case run (instead of aborting at first
failure) and print the ones that failed. The second patch is the actual
fix.
The patch
-4.c: Likewise.
* gcc.dg/builtin-object-size-6.c: Likewise.
* gcc.dg/builtin-object-size-7.c: Likewise.
* gcc.dg/builtin-object-size-8.c: Likewise.
* gcc.dg/pr101836.c: Likewise.
* gcc.dg/strict-flex-array-3.c: Likewise.
Signed-off-by: Siddhesh Poyarekar
-flex-nonzero.c: New test.
* gcc.dg/builtin-object-size-flex-zero.c: New test.
* gcc.dg/builtin-object-size-flex.c: New test.
Signed-off-by: Siddhesh Poyarekar
---
.../g++.dg/ext/builtin-object-size1.C | 10 +-
.../g++.dg/ext/builtin-object-size2.C | 10 +-
gcc
with
--with-build-config=bootstrap-ubsan to make sure that there are no new
failures due to this change.
Siddhesh Poyarekar (2):
testsuite: Run __bos tests to completion
tree-object-size: More consistent behaviour with flex arrays
.../g++.dg/ext/builtin-object-size1.C | 267
/ChangeLog:
PR tree-optimization/105043
* doc/extend.texi (Object Size Checking): Split out into two
subsections and mention _FORTIFY_SOURCE.
Signed-off-by: Siddhesh Poyarekar
---
gcc/doc/extend.texi | 20 ++--
1 file changed, 14 insertions(+), 6 deletions
On 2022-12-15 12:09, Jakub Jelinek wrote:
-This is a propagation pass similar to CCP that tries to remove calls
-to @code{__builtin_object_size} when the size of the object can be
-computed at compile-time. This pass is located in
-@file{tree-object-size.cc} and is described by
+This is a
(Optimize calls to @code{__builtin_object_size}): Also mention
__builtin_dynamic_object_size.
Signed-off-by: Siddhesh Poyarekar
---
gcc/doc/extend.texi | 10 --
gcc/doc/passes.texi | 11 ++-
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/gcc/doc/extend.texi
-by: Siddhesh Poyarekar
---
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index f48df64cc2a..a50417a4ab7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -16744,8 +16744,8 @@ or when a method
On 2022-12-05 11:38, Jeff Law wrote:
On 12/5/22 07:28, Siddhesh Poyarekar wrote:
In commit e5cfb9cac1d7aba9a8ea73bfe7922cfaff9d61f3 I introduced tests
for strdup and strndup with leaks. Fix those leaks.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-dynamic-object-size-0.c (test_strdup
In commit e5cfb9cac1d7aba9a8ea73bfe7922cfaff9d61f3 I introduced tests
for strdup and strndup with leaks. Fix those leaks.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-dynamic-object-size-0.c (test_strdup,
test_strndup, test_strdup_min, test_strndup_min): Free RES
before
On 2022-12-01 18:19, Kees Cook wrote:
On Thu, Dec 01, 2022 at 10:27:41PM +, Qing Zhao wrote:
Hi, Sid,
Thanks a lot for the input.
After more thinking based on your and Kees’ comments, I have the following
thought:
1. -fstrict-flex-arrays=level should control both GCC code gen and
On 2022-12-01 11:42, Kees Cook wrote:
On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
'-Wstrict-flex-arrays'
Warn about inproper usages of flexible array members according to
the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
the trailing array field
On 2022-11-22 15:43, Jeff Law wrote:
On 11/21/22 07:27, Siddhesh Poyarekar wrote:
On 2022-11-20 10:42, Jeff Law wrote:
On 11/4/22 06:48, Siddhesh Poyarekar wrote:
Use string length of input to strdup to determine the usable size of
the
resulting object. Avoid doing the same for strndup
On 2022-11-20 10:42, Jeff Law wrote:
On 11/4/22 06:48, Siddhesh Poyarekar wrote:
Use string length of input to strdup to determine the usable size of the
resulting object. Avoid doing the same for strndup since there's a
chance that the input may be too large, resulting in an unnecessary
Ping!
On 2022-11-04 08:48, Siddhesh Poyarekar wrote:
Use string length of input to strdup to determine the usable size of the
resulting object. Avoid doing the same for strndup since there's a
chance that the input may be too large, resulting in an unnecessary
overhead or worse, the input may
On 2022-11-04 09:43, Prathamesh Kulkarni wrote:
On Fri, 4 Nov 2022 at 18:18, Siddhesh Poyarekar wrote:
Use string length of input to strdup to determine the usable size of the
resulting object. Avoid doing the same for strndup since there's a
chance that the input may be too large, resulting
Use string length of input to strdup to determine the usable size of the
resulting object. Avoid doing the same for strndup since there's a
chance that the input may be too large, resulting in an unnecessary
overhead or worse, the input may not be NULL terminated, resulting in a
crash where there
On 2022-09-23 09:02, Jakub Jelinek wrote:
Oh, so can addr_object_size be simplified to use get_base_address too?
You can try. As you can see in get_base_address, that function
handles something that the above doesn't (looking through some MEM_REFs too).
I went down this rabbithole and it
On 2022-09-22 09:02, Jakub Jelinek wrote:
On Mon, Aug 15, 2022 at 03:23:11PM -0400, Siddhesh Poyarekar wrote:
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -495,6 +495,18 @@ decl_init_size (tree decl, bool min)
return size;
}
+/* Get the outermost object that PTR may
Ping!
On 2022-09-07 15:21, Siddhesh Poyarekar wrote:
Ping!
On 2022-08-29 10:16, Siddhesh Poyarekar wrote:
Ping!
On 2022-08-15 15:23, Siddhesh Poyarekar wrote:
Use string length of input to strdup to determine the usable size of the
resulting object. Avoid doing the same for strndup since
Ping!
On 2022-08-29 10:16, Siddhesh Poyarekar wrote:
Ping!
On 2022-08-15 15:23, Siddhesh Poyarekar wrote:
Use string length of input to strdup to determine the usable size of the
resulting object. Avoid doing the same for strndup since there's a
chance that the input may be too large
Ping!
On 2022-08-15 15:23, Siddhesh Poyarekar wrote:
Use string length of input to strdup to determine the usable size of the
resulting object. Avoid doing the same for strndup since there's a
chance that the input may be too large, resulting in an unnecessary
overhead or worse, the input may
Use string length of input to strdup to determine the usable size of the
resulting object. Avoid doing the same for strndup since there's a
chance that the input may be too large, resulting in an unnecessary
overhead or worse, the input may not be NULL terminated, resulting in a
crash where there
On 10/07/2022 21:44, Jeff Law wrote:
This may all argue that these warnings don't belong in -Wall, which is
obviously a distinct, but vitally important discussion. I've always
believed that we can make an educated guess about whether or not to
include any given warning in -Wall, but we have
On 10/07/2022 08:59, Jeff Law via Gcc-patches wrote:
On 3/9/2022 5:39 PM, Siddhesh Poyarekar wrote:
The size argument larger than size of SRC for strnlen and strndup is
problematic only if SRC is not NULL terminated, which invokes undefined
behaviour. In all other cases, as long as SRC
On 20/06/2022 15:20, Jakub Jelinek wrote:
On Tue, Jun 14, 2022 at 09:01:54PM +0530, Siddhesh Poyarekar wrote:
The addr_expr computation does not check for error_mark_node before
returning the size expression. This used to work in the constant case
because the conversion to uhwi would end up
Hello,
ping!
On 14/06/2022 21:01, Siddhesh Poyarekar wrote:
The addr_expr computation does not check for error_mark_node before
returning the size expression. This used to work in the constant case
because the conversion to uhwi would end up causing it to return
size_unknown, but that won't
-optimization/105736
* gcc.dg/builtin-dynamic-object-size-0.c (TV4, val3,
test_pr105736): New struct declaration, variable and function to
test PR.
(main): Use them.
Signed-off-by: Siddhesh Poyarekar
---
Changes from v1:
- Used FAIL() instead of __builtin_abort
-optimization/105736
* gcc.dg/builtin-dynamic-object-size-0.c (TV4, val3,
test_pr105736): New struct declaration, variable and function to
test PR.
(main): Use them.
Signed-off-by: Siddhesh Poyarekar
---
Tested:
- x86_64 bootstrap and test
- --with-build-config
/bind-c-intent-out-2.f90 does not crash anymore.
gcc/ChangeLog:
PR middle-end/70090
* asan.cc (initialize_sanitizer_builtins): Register
__builtin_dynamic_object_size if necessary.
Signed-off-by: Siddhesh Poyarekar
---
Testing:
- I realized that for some reason I was looking
On 10/05/2022 16:16, Martin Liška wrote:
The revision caused:
$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/ubsan/bind-c-intent-out-2.f90
-fsanitize=undefined -c -O
during GIMPLE pass: ubsan
On 07/02/2022 17:37, Jakub Jelinek wrote:
On Mon, Feb 07, 2022 at 05:31:58PM +0530, Siddhesh Poyarekar wrote:
Use __builtin_dynamic_object_size to get object sizes for ubsan.
gcc/ChangeLog:
middle-end/70090
* ubsan.cc (ubsan_expand_objsize_ifn): Allow non-constant SIZE
On 10/03/2022 06:09, Siddhesh Poyarekar wrote:
The size argument larger than size of SRC for strnlen and strndup is
problematic only if SRC is not NULL terminated, which invokes undefined
behaviour. In all other cases, as long as SRC is large enough to have a
NULL char (i.e. size 1 or more
On 25/03/2022 18:56, Jason Merrill via Gcc-patches wrote:
Perhaps a suitable compromise would be to add a separate warning flag
specifically for the strn* warnings, so users deliberately using the
bound to express a limit other than the length of the argument string
(and confident that their
:
PR tree-optimization/104970
* gcc.dg/builtin-dynamic-object-size-0.c (test_parmsz_simple2,
test_parmsz_simple3, test_parmsz_extern, test_parmsz_internal,
test_parmsz_internal2, test_parmsz_internal3): New tests.
(main): Use them.
Signed-off-by: Siddhesh Poyarekar
On 17/03/2022 23:21, Martin Sebor wrote:
On 3/17/22 11:22, Siddhesh Poyarekar wrote:
On 17/03/2022 22:16, Jeff Law wrote:
#include
char a[] = "abc";
char b[] = "abcd";
int f (void)
{
return strncmp (a, b, 8);
}
where I get
t.c:7:1
On 17/03/2022 22:16, Jeff Law wrote:
#include
char a[] = "abc";
char b[] = "abcd";
int f (void)
{
return strncmp (a, b, 8);
}
where I get
t.c:7:10: warning: ‘strncmp’ specified bound 8 exceeds source size 5
[-Wstringop-overread]
7 |
On 17/03/2022 05:11, Martin Sebor wrote:
As the GCC manual prominently states (and as I already pointed out)
warnings are:
We are indeed going around in circles. Hopefully someone else will
pitch in and break the deadlock.
Siddhesh
-size-0.c (S1, S2): New structs.
(test_alloc_nested_structs, g): New functions.
(main): Call test_alloc_nested_structs.
Signed-off-by: Siddhesh Poyarekar
---
Testing:
- x86_64 bootstrap build and check
- i686 build and check
.../gcc.dg/builtin-dynamic-object-size-0.c| 34
(alloc_object_size): Remove STRIP_NOPS.
gcc/testsuite/ChangeLog:
tree-optimization/104942
* gcc.dg/builtin-dynamic-object-size-0.c (alloc_func_long,
test_builtin_malloc_long): New functions.
(main): Use it.
Signed-off-by: Siddhesh Poyarekar
---
Testing:
- i686 build
On 16/03/2022 02:06, Martin Sebor wrote:
The intended use of the strncmp bound is to limit the comparison to
at most the size of the arrays or (in a subset of cases) the length
of an initial substring. Providing an arbitrary bound that's not
related to the sizes as you describe sounds very much
On 15/03/2022 21:09, Martin Sebor wrote:
The strncmp function takes arrays as arguments (not necessarily
strings). The main purpose of the -Wstringop-overread warning
for calls to it is to detect calls where one of the arrays is
not a nul-terminated string and the bound is larger than the size
(pass_waccess::warn_zero_sized_strncmp_inputs): New function.
(pass_waccess::check_strncmp): Use it.
gcc/testsuite/ChangeLog:
middle-end/104854
* gcc.dg/Wstringop-overread.c (test_strncmp_array): Don't expect
failures for non-zero sizes.
Signed-off-by: Siddhesh Poyarekar
/testsuite/ChangeLog:
middle-end/104854
* gcc.dg/Wstringop-overread.c (test_strncmp_array): Don't expect
failures for non-zero sizes.
Signed-off-by: Siddhesh Poyarekar
---
x86_64 bootstrap in progress.
gcc/gimple-ssa-warn-access.cc | 39
string-4.c (strnlen_range): Likewise.
* gcc.dg/pr78902.c: Likewise.
* gcc.dg/warn-strnlen-no-nul.c: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
Tested with an x86_64 bootstrap. strncmp has a similar issue, I'll post a
separate patch for it.
gcc/gimple-ssa-warn-access.cc
/70090
* gcc.dg/ubsan/object-size-dyn.c: New test.
Signed-off-by: Siddhesh Poyarekar
---
Proposing for gcc13 since I reckoned this is not feasible for stage 4.
Tested with:
- ubsan bootstrap config on x86_64
- bootstrap build and test on x86_64
- non-bootstrap build and test with i686
gcc
Signed-off-by: Siddhesh Poyarekar
---
htdocs/gcc-12/changes.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index c69b301e..c6baee75 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -157,6 +157,8
zero size for negative offsets.
* gcc.dg/builtin-object-size-4.c (test8): Likewise.
* gcc.dg/builtin-object-size-5.c (test7): Drop test for
__builtin_object_size.
Signed-off-by: Siddhesh Poyarekar
---
Testing:
- bootstrap build+test for x86_64
- build+test for i686
On 11/01/2022 19:04, Jakub Jelinek wrote:
On Tue, Jan 11, 2022 at 06:40:44PM +0530, Siddhesh Poyarekar wrote:
Never try to compute size for offset when the object size is -1, which
is either unknown maximum or uninitialized minimum irrespective of the
osi->pass number.
gcc/Change
oid
computing offset for -1 size.
gcc/testsuite/ChangeLog:
PR tree-optimization/pr103961
* gcc.dg/pr103961.c: New test case.
Co-authored-by: Jakub Jelinek
Signed-off-by: Siddhesh Poyarekar
---
Tested with i686 build+test, x86_64 bootstrap build+test and ubsan
bootstrap.
gcc/testsu
On 11/01/2022 15:13, Jakub Jelinek wrote:
On Tue, Jan 11, 2022 at 02:27:47PM +0530, Siddhesh Poyarekar wrote:
Handle GIMPLE_PHI and conditionals specially for dynamic objects,
returning PHI/conditional expressions instead of just a MIN/MAX
estimate.
This makes the returned object size variable
)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-3.c (test1)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-4.c (test1)
[__builtin_object_size]: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object
)
[__builtin_object_size]: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object-size-0.c| 156 ++
gcc/testsuite/gcc.dg/builtin-object-size-1.c | 30 +++-
gcc/testsuite/gcc.dg/builtin-object-size-2.c | 43 -
gcc/testsuite/gcc.dg/builtin-object
[__builtin_object_size]:
Likewise.
* gcc.dg/builtin-object-size-4.c [__builtin_object_size]:
Likewise.
* gcc.dg/builtin-object-size-5.c [__builtin_object_size]:
Likewise.
Signed-off-by: Siddhesh Poyarekar
---
gcc/builtins.c
/builtin-dynamic-object-size-0.c (test_parmsz_simple,
test_parmsz_scaled, test_parmsz_unknown): New functions.
(main): Call them. Add new arguments argc and argv.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object-size-0.c| 35 +++-
gcc/tree-object
performance impact on applications on building with
_FORTIFY_SOURCE=3.
Changes from v5:
- Address review comments
- Add a couple more tests for object sizes of pointers passed as
parameters.
Siddhesh Poyarekar (4):
tree-object-size: Support dynamic sizes in conditions
tree-object-size: Handle
On 10/01/2022 16:20, Jakub Jelinek wrote:
On Sat, Dec 18, 2021 at 06:05:09PM +0530, Siddhesh Poyarekar wrote:
@@ -1440,6 +1441,53 @@ cond_expr_object_size (struct object_size_info *osi,
tree var, gimple *stmt)
return reexamine;
}
+/* Find size of an object passed as a parameter
On 10/01/2022 16:07, Jakub Jelinek wrote:
You test the above with both possibilities.
+ if (test_builtin_calloc_condphi (128, 1, 0) == 128)
+FAIL ();
But not this one, why? Also, it would be better to have
a != ... test rather than ==, if it is the VLA, then 128 * sizeof (struct { int
/77608
* gcc.dg/builtin-object-size-1.c (test1): Add tests.
* gcc.dg/builtin-object-size-2.c (test1): Likewise.
Signed-off-by: Siddhesh Poyarekar
---
This applies on top of the __builtin_dynamic_object_size patchset. It
should be possible to process trees with side effects
Happy new year, and ping!
On 12/18/21 18:05, Siddhesh Poyarekar wrote:
This patchset enhances the __builtin_dynamic_object_size builtin to
produce dynamic expressions for object sizes to improve coverage of
_FORTIFY_SOURCE.
Testing:
This series has been tested with build and test
)
[__builtin_object_size]: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object-size-0.c| 158 ++
gcc/testsuite/gcc.dg/builtin-object-size-1.c | 30 +++-
gcc/testsuite/gcc.dg/builtin-object-size-2.c | 43 -
gcc/testsuite/gcc.dg/builtin-object
)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-3.c (test1)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-4.c (test1)
[__builtin_object_size]: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
Changes since v4:
- Free allocations
[__builtin_object_size]:
Likewise.
* gcc.dg/builtin-object-size-4.c [__builtin_object_size]:
Likewise.
* gcc.dg/builtin-object-size-5.c [__builtin_object_size]:
Likewise.
Signed-off-by: Siddhesh Poyarekar
---
Changes since v4:
- Propagate sameness of size
/builtin-dynamic-object-size-0.c (test_parmsz_simple):
New function.
(main): Call it.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object-size-0.c| 11
gcc/tree-object-size.c| 50 ++-
2 files changed, 60 insertions
and this new one. Also compare with
__builtin_dynamic_object_size.
- Expand the list of packages to get more coverage metrics.
- Explore performance impact on applications on building with
_FORTIFY_SOURCE=3.
Siddhesh Poyarekar (4):
tree-object-size: Support dynamic sizes in conditions
tree-object
tree-optimization/103759
* tree-object-size (unknown, initval): Remove functions.
(size_unknown, size_initval, size_unknown_p): Operate directly
on trees.
Signed-off-by: Siddhesh Poyarekar
---
Tested a full bootstrap on x86_64, config=ubsan-bootstrap and i686.
Changes from
:
PR tree-optimization/103759
* tree-object-size (unknown, initval): Change to arrays. Adjust
all uses.
(init_limits): Rename from init_offset_limit. Initialize
UNKNOWN and INITVAL. Adjust all uses.
Signed-off-by: Siddhesh Poyarekar
---
Changes from v1
:
PR tree-optimization/103759
* tree-object-size (size_unknown_p): Construct a size_unknown
and compare with VAL.
Signed-off-by: Siddhesh Poyarekar
---
This fixes all the 32-bit torture failures on i686, tested with
configuration:
--enable-clocale=gnu --with-system-zlib
On 12/18/21 00:59, David Edelsohn wrote:
Siddhesh,
This patch series seems to have caused testsuite regressions for
memcpy-chk, etc. in 32 bit mode (i386, x86-64 -m32 and -mx32, AIX 32
bit).
I have opened PR 103759.
Thanks, I've assigned it to myself. I'll take a look.
Siddhesh
On 12/16/21 21:19, Jakub Jelinek wrote:
Yes, but please fix up formatting, wholeval should go below old_wholeval.
Though, perhaps it would be better to:
if (tree_int_cst_compare (oldval, val))
return true;
gcc_checking_assert (tree_int_cst_compare (old_wholeval, wholeval) == 0);
101 - 200 of 377 matches
Mail list logo
