On 2025-07-11 15:28, Uros Bizjak wrote:
Why not just switch over unconditionally? __fentry__ seems like a
better alternative to mcount overall and it has been around long enough
that even older deployments should be relatively unaffected.
Actually, it is switched on by default for i?86-*-linux
The test ends up writing a byte beyond bounds of the buffer, which gets
trapped on some targets when the test is run with
-fstack-protector-strong.
testsuite/ChangeLog:
* gcc.dg/vect/pr116125.c (mem_overlap): Reduce iteration count
to 8.
Signed-off-by: Siddhesh Poyarekar
---
OK
On 2025-07-08 18:07, Sam James wrote:
OK in principle, but please allow some time for distro maintainers
(CC'd) to voice their opinion.
It looks good to me and I plan on us using it. I'd like opinions from
one other group first before it goes in if possible though, as our
perspective is differe
On 2025-07-09 04:21, Thomas Schwinge wrote:
Fix-up for commit 72e85d46472716e670cbe6e967109473b8d12d38
"tree-optimization/120780: Support object size for containing objects".
'size_t sz' is unused here, and GCC/nvptx doesn't accept this:
spawn -ignore SIGHUP [...]/nvptx-none-run
./builtin-
On 2025-07-08 18:18, Qing Zhao wrote:
On Jul 8, 2025, at 17:46, Siddhesh Poyarekar wrote:
On 2025-07-08 17:17, Qing Zhao wrote:
Are the above the correct and efficient updates to the .ACCESS_WITH_SIZE to
resolve both PR121000 and the issue
we have with counted_by for pointers?
I don't
On 2025-07-08 17:17, Qing Zhao wrote:
Are the above the correct and efficient updates to the .ACCESS_WITH_SIZE to
resolve both PR121000 and the issue
we have with counted_by for pointers?
I don't know about PR121000, but for counted_by with pointers, I think
the REF_TO_OBJ (and the result_typ
On 2025-07-07 17:47, Jakub Jelinek wrote:
Even 6 arguments is IMHO too much.
/* Expand the IFN_ACCESS_WITH_SIZE function:
ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, CLASS_OF_SIZE,
TYPE_OF_SIZE, ACCESS_MODE)
which returns the REF_TO_OBJ same as the 1st argument;
On 2025-07-07 13:07, Qing Zhao wrote:
If the current bug is urgent to be fixed. and you are not comfortable with the
simple Patch Sid provided, then I am okay to back it out now and then push it
back with the fix to this current bug at a later time after everyone is
comfortable with the curren
On 2025-07-07 09:33, Siddhesh Poyarekar wrote:
The only difference between &a->fam[0] and &a->fam is not the value
(that is
the same), just the type in one case say int *, in the other int [0:] *.
At least in GIMPLE pointer conversions are useless, so what exact type of
the argum
On 2025-07-07 09:14, Jakub Jelinek wrote:
So that ought to be &a->fam[0] right, and not &a->fam? It means the same
for a FAM, so why not specify it as &a->fam[0] (or simply a->fam)? That will
be consistent with when fam is a pointer.
The only difference between &a->fam[0] and &a->fam is not th
On 2025-07-07 08:48, Jakub Jelinek wrote:
The return value of .ACCESS_WITH_SIZE clobbering PTR (that subsequently gets
passed to __builtin_dynamic_object_size) should be sufficient to fully
prevent the reordering, it shouldn't have to clobber &PTR, I think.
The original use of .ACCESS_WITH_SIZE
On 2025-07-07 03:05, Richard Biener wrote:
Since the intent of the .ACCESS_WITH_SIZE was to associate the storage
of count with c to prevent reordering, maybe the semantically correct
solution here is that when c is a pointer, the frontend emits:
_2 = a->c;
_3 = &a->count;
_1 = .ACCE
On 2025-07-05 07:23, Richard Biener wrote:
OK, should I revert right away or can we wait till Qing returns on Monday?
Monday is OK with me.
Thanks, so I thought about this some more and I think when I said in
bugzilla:
"In fact, maybe the .ACCESS_WITH_SIZE handling in objsz probably needs
On 2025-07-05 02:45, Richard Biener wrote:
Am 04.07.2025 um 19:57 schrieb Siddhesh Poyarekar :
On 2025-07-04 08:12, Siddhesh Poyarekar wrote:
On 2025-07-04 08:08, Siddhesh Poyarekar wrote:
gcc/ChangeLog:
I forgot to add the PR number to the ChangeLog entries, I've fixed it in my
c
On 2025-07-04 08:12, Siddhesh Poyarekar wrote:
On 2025-07-04 08:08, Siddhesh Poyarekar wrote:
gcc/ChangeLog:
I forgot to add the PR number to the ChangeLog entries, I've fixed it in
my commit message.
* tree-object-size.cc (is_access_with_size): New fun
On 2025-07-04 08:08, Siddhesh Poyarekar wrote:
gcc/ChangeLog:
I forgot to add the PR number to the ChangeLog entries, I've fixed it in
my commit message.
* tree-object-size.cc (is_access_with_size): New function.
(collect_object_sizes_for): Use it.
gcc/testsuite/Chan
function.
(collect_object_sizes_for): Use it.
gcc/testsuite/ChangeLog:
* gcc.dg/pr120929.c: New test case.
Signed-off-by: Siddhesh Poyarekar
---
Bootstraps in progress.
gcc/testsuite/gcc.dg/pr120929.c | 57 +
gcc/tree-object-size.cc | 40
On 2025-07-03 03:13, Jakub Jelinek wrote:
On Thu, Jul 03, 2025 at 08:33:45AM +0200, Richard Biener wrote:
On Wed, Jul 2, 2025 at 11:32 PM Siddhesh Poyarekar wrote:
MEM_REF cast of a subobject to its containing object has negative
offsets, which objsz sees as an invalid access. Support this
-optimization/120780
* gcc.dg/builtin-dynamic-object-size-pr120780.c: New test case.
Signed-off-by: Siddhesh Poyarekar
---
Changes from v2:
* Skip over sub-byte offsets
Changes from v1:
* Use byte_position to get byte position of a field
Testing:
- x86_64 bootstrap and test
- i686 build and
On 2025-06-27 08:39, Siddhesh Poyarekar wrote:
MEM_REF cast of a subobject to its containing object has negative
offsets, which objsz sees as an invalid access. Support this use case
by peeking into the structure to validate that the containing object
indeed contains a type of the subobject at
On 2025-06-27 08:05, Jakub Jelinek wrote:
On Fri, Jun 27, 2025 at 02:00:26PM +0200, Richard Biener wrote:
+ gcc_assert (RECORD_OR_UNION_TYPE_P (container));
+
+ for (tree t = TYPE_FIELDS (container); t; t = DECL_CHAIN (t))
+{
+ if (TREE_CODE (t) != FIELD_DECL)
+continue;
+
+
-optimization/120780
* gcc.dg/builtin-dynamic-object-size-pr120780.c: New test case.
Signed-off-by: Siddhesh Poyarekar
---
Testing notes:
- Local tests continue to look good.
- Bootstraps in progress.
.../builtin-dynamic-object-size-pr120780.c| 233 ++
gcc/tree-object
On 2025-06-27 07:40, Siddhesh Poyarekar wrote:
MEM_REF cast of a subobject to its containing object has negative
offsets, which objsz sees as an invalid access. Support this use case
by peeking into the structure to validate that the containing object
indeed contains a type of the subobject at
-optimization/120780
* gcc.dg/builtin-dynamic-object-size-pr120780.c: New test case.
Signed-off-by: Siddhesh Poyarekar
---
.../builtin-dynamic-object-size-pr120780.c| 233 ++
gcc/tree-object-size.cc | 87 ++-
2 files changed, 319 insertions
On 2025-06-24 03:26, Richard Biener wrote:
+ /* Handle the following stmt #2 to propagate the size from the
+ stmt #1 to #3:
+ 1 _1 = .ACCESS_WITH_SIZE (_3, _4, 1, 0, -1, 0B);
+ 2 _5 = *_1;
+ 3 _6 = __builtin_dynamic_object_size
On 2025-06-23 10:42, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): Update comments
for pointers with .ACCESS_WITH_SIZE.
(collect_object_sizes_for): Propagate size info through GIMPLE_ASSIGN
for pointers with .ACCESS_WITH_SIZ
On 2025-06-20 11:26, Qing Zhao wrote:
the mentioned code change:
+else if (TREE_CODE (rhs) == MEM_REF
+ && POINTER_TYPE_P (TREE_TYPE (rhs))
+ && TREE_CODE (TREE_OPERAND (rhs, 0)) == SSA_NAME)
+ reexamine = merge_object_sizes (osi, var, TREE_OPERAND (rhs
On 2025-06-20 10:22, Qing Zhao wrote:
Okay, this is a reasonable solution to this problem.
I will add a new —param option as suggested, and then guard the generation of
the size expression for:
__builtin_dynamic_object_size (p, 1)
With this opinion before the NULL pointer checking. Then upda
On 2025-06-19 12:07, Siddhesh Poyarekar wrote:
On 2025-06-16 18:08, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): Handle pointers
with counted_by.
This should probably just say "Update comment for .ACCESS_WITH
On 2025-06-16 18:08, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): Handle pointers
with counted_by.
This should probably just say "Update comment for .ACCESS_WITH_SIZE.".
(collect_object_sizes_for): Likewise.
gcc/testsuite/Chan
On 2025-06-18 18:40, Qing Zhao wrote:
Okay, I guess that I didn’t put enough attention on the above example
previously, sorry about that...
Read it multiple times this time, my question is for the following code portion:
objsz = __builtin_dynamic_object_size (ptr, 0);
__memcpy_chk (ptr, src,
On 2025-06-18 17:46, Qing Zhao wrote:
Okay, I guess that I didn’t put enough attention on the above example
previously, sorry about that...
Read it multiple times this time, my question is for the following code portion:
objsz = __builtin_dynamic_object_size (ptr, 0);
__memcpy_chk (ptr, src
On 2025-06-18 17:16, Kees Cook wrote:
I agree, validating invalid pointers is not the job of __bdos. My concern
is about having __bdos *generate* code that results in invalid pointer
access.
I would like a way to indicate the desire to do the dereference. Having
an invalid pointer is a totally
On 2025-06-18 16:20, Qing Zhao wrote:
On Jun 18, 2025, at 15:50, Siddhesh Poyarekar wrote:
On 2025-06-18 15:14, Qing Zhao wrote:
struct fam_container
{
int a;
int count;
char fam[] __counted_by__ (count);
};
size_t
baz (struct fam_container *ptr)
{
...
ptr->count
On 2025-06-18 15:14, Qing Zhao wrote:
struct fam_container
{
int a;
int count;
char fam[] __counted_by__ (count);
};
size_t
baz (struct fam_container *ptr)
{
...
ptr->count = 0;
__builtin_free (ptr);
...
return 0;
}
void
bar (size_t insz)
{
struct fam_container *c =
__builtin_
On 2025-06-18 10:32, Qing Zhao wrote:
A NULL check alone does not solve this problem because the pointer could be
arbitrary and invalid. I thought some more about adding the size expression
only if there's an existing access like I suggested in that email, but I
realize that doesn't make sens
On 2025-05-07 12:59, Qing Zhao wrote:
Hi,
This is the 2nd version of the patch for:
Evaluate the object size by the size of the pointee type when the type
is a structure with flexible array member which is annotated with
counted_by.
Per the following discussion: (Questions on replacing a struc
On 2025-04-11 13:37, Martin Uecker wrote:
My understanding is that such issue with the implicit data flow dependency
information missing is only for the
counted_by attribute, not for the other TYPE which already have the bound
information there.
The dependency issue is only for the size, but
On 2025-04-10 01:41, Martin Uecker wrote:
I have some questions about this: The access would add new reads
to the size field. For counted_by, so far, those are somehow
coupled to the access to the member. From this you would assume
For the currently implemented subset, updates to the storage
On 2025-04-10 11:12, Martin Uecker wrote:
range-ops is setup to pull range information from builtin functions
already in gimple-range-op.cc::
gimple_range_op_handler::maybe_builtin_call (). We'd just need to write
a handler for this new one. You can pull information from 2 operands
under normal
On 2025-04-10 10:50, Andrew MacLeod wrote:
Its not clear to me exactly what is being asked, but I think the
suggestion is that pointer references are being replaced with a builtin
function called .ACCESS_WITH_SIZE ? and I presume that builtin
function has some parameters that give you releva
On 2025-04-10 07:48, Martin Uecker wrote:
For the currently implemented subset, updates to the storage of the
annotated FAM and updates to its counted_by size need to be coupled to
prevent reordering because their relationship is otherwise implicit.
This proposed feature would need the counted_b
On 2025-04-08 12:41, Qing Zhao wrote:
The gimple IR is:
1 int main ()
2 {
3 int D.5072;
4
5 {
6 struct annotated * q;
7
8 q = alloc_buf (10);
9 _1 = __builtin_dynamic_object_size (q, 1);
10 __builtin_printf ("the bdos whole is %d\n", _1);
11
On 2025-04-09 08:30, Qing Zhao wrote:
After expand phase, .ACCESS_WITH_SIZE will be replaced by its first argument.
And all the size expression before the call to .ACCESS_WITH_SIZE might be dead
code eliminated later in the RTL phases.
So, I don’t think there will be run-time overhead concern.
On 2025-04-08 15:22, Qing Zhao wrote:
Changing a pointer reference to a call to .ACCESS_WITH_SIZE will impact the
compiler optimization in two aspects:
1. The new call site might become a barrier that prevents code movement around
it.
Yeah, it's not a real problem IMO; it should only preven
On 2025-04-08 12:41, Qing Zhao wrote:
For the following small example:
[ counted_by_whole]$ cat t.c
#include
#include
struct annotated {
size_t count;
char other;
char array[] __attribute__((counted_by (count)));
};
#define MAX(A, B) (A > B) ? (A) : (B)
#define ALLOC_SIZE_ANNOTATED(
On 2025-04-07 14:53, Qing Zhao wrote:
Is there a reason to do this at the very end like this and not in the
GIMPLE_ASSIGN case in the switch block? Something like this:
tree rhs = gimple_assign_rhs1 (stmt);
tree counted_by_ref = NULL_TREE;
if (gimple_assign_rhs_code
On 2025-04-07 11:56, Qing Zhao wrote:
when the type is a structure with flexible array member.
Not just when the structure has a flexible array member, also when the
FAM size is recorded in a __counted_by__, isn't it?
In tree-object-size.cc, if the size is UNKNOWN after evaluating use-def
c
On 2025-01-29 08:24, Jakub Jelinek wrote:
On Wed, Jan 29, 2025 at 08:19:38AM -0500, Siddhesh Poyarekar wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so
XFAIL some gfortran tests only for targets with the IBM128 long double
ABI.
gcc/testsuite/ChangeLog:
PR
procedure.
* gfortran.dg/default_format_2.f90: xfail for
long_double_is_ibm128.
* gfortran.dg/default_format_denormal_2.f90: Likewise.
* gfortran.dg/large_real_kind_form_io_2.f90: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
Change from v5:
- bring back v4 and
On 2025-01-29 07:34, Jakub Jelinek wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
If long double is just IEEE754 double, then I think denormals
are equally well behaved, it is so
s.exp
(check_effective_target_ppc_not_well_defined_denormals): New
procedure.
* gfortran.dg/default_format_2.f90: xfail for
ppc_not_well_defined_denormals.
* gfortran.dg/default_format_denormal_2.f90: Likewise.
* gfortran.dg/large_real_kind_form_io_2.f90: Likewise.
Signed-off-by: Siddhesh Poya
On 2025-01-28 21:01, Siddhesh Poyarekar wrote:
However, the previous test XFAILed the test for all PowerPC compiles
and your new one only XFAILs it for IBM128. That allows our two other
long double options to not be XFAILed. IEEE128 which is actually
expected
to PASS and --without-long
On 2025-01-28 20:57, Peter Bergner wrote:
On 1/28/25 4:51 PM, Siddhesh Poyarekar wrote:
So the reason why I didn't go the __LONG_DOUBLE_IEEE128__ route because
the check would then have to be something like:
powerpc*-*-* && ! ppc_default_long_double_ieee
Ah, that makes sense
s.exp
(check_effective_target_ppc_default_long_double_ibm): New
procedure.
* gfortran.dg/default_format_2.f90: xfail for
ppc_default_long_double_ibm.
* gfortran.dg/default_format_denormal_2.f90: Likewise.
* gfortran.dg/large_real_kind_form_io_2.f90: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
Ch
On 2025-01-28 17:12, Peter Bergner wrote:
On 1/28/25 11:43 AM, Siddhesh Poyarekar wrote:
+return [check_runtime_nocache ppc_default_long_double_ibm {
+ ! Fortran
+ program default_long_double_ibm
+integer, parameter :: kl = selected_real_kind (precision (0.0_8) + 1
s.exp
(check_effective_target_ppc_default_long_double_ibm): New
procedure.
* gfortran.dg/default_format_2.f90: xfail for
ppc_default_long_double_ibm.
* gfortran.dg/default_format_denormal_2.f90: Likewise.
* gfortran.dg/large_real_kind_form_io_2.f90: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
Ver
On 2025-01-10 07:50, Siddhesh Poyarekar wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
gcc/testsuite/ChangeLog:
PR testsuite/118127
* lib/target-support
On 2025-01-06 11:34, Jakub Jelinek wrote:
That looks incorrect to me.
ppc_ieee128_ok just means that one can use the __ieee128 type (and only if
-mfloat128 option is passed).
What the tests care is whether real(16) is IEEE128 or IBM128.
That is dependent on what glibc gcc has been configured agai
s.exp
(check_effective_target_ppc_default_long_double_ibm): New
procedure.
* gfortran.dg/default_format_2.f90: Don't xfail for
ppc_default_long_double_ibm.
* gfortran.dg/default_format_denormal_2.f90: Likewise.
* gfortran.dg/large_real_kind_form_io_2.f90: Likewise.
Signed-off-by: Siddhesh Poyarekar
Ping!
On 2024-12-19 08:16, Siddhesh Poyarekar wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
gcc/testsuite/ChangeLog:
PR testsuite/118127
* gfortr
ieee128_ok.
* gfortran.dg/default_format_denormal_2.f90: Likewise.
* gfortran.dg/large_real_kind_form_io_2.f90: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gfortran.dg/default_format_2.f90 | 2 +-
gcc/testsuite/gfortran.dg/default_format_denormal_2.f90 |
On 2024-12-05 05:37, Richard Biener wrote:
VN again is the culprit for exploiting address equivalences before
__builtin_object_size got the chance to do its job. This time
it isn't about union members but adjacent structure fields where
an address to one after the last element of an array field
e-3.c (test10): Adjust expected size.
Signed-off-by: Siddhesh Poyarekar
---
Testing:
- bootstrapped on x86_64
- tested on i686, no new regressions
- bootstrapp with config-ubsan in progress
.../g++.dg/ext/builtin-object-size2.C | 27 ++
gcc/testsuite/gcc.dg/builtin-object
t-size-1.c (test12): New test.
(main): Call it.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/builtin-object-size-1.c | 21
gcc/tree-object-size.cc | 6 +++---
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/gcc/t
On 2024-09-27 06:31, Jakub Jelinek wrote:
On Fri, Sep 20, 2024 at 12:40:26PM -0400, Siddhesh Poyarekar wrote:
When wholesize != size, there is a reasonable opportunity for static
object sizes also to be computed using size_for_offset, so use that.
gcc/ChangeLog:
* tree-object-size.cc
On 2024-10-04 10:03, Siddhesh Poyarekar wrote:
diff --git a/libstdc++-v3/testsuite/17_intro/names.cc
b/libstdc++-v3/testsuite/17_intro/names.cc
index 6b9a3639aad..bbf45b93dee 100644
--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -377,4 +377,11
On 2024-10-04 07:52, Jonathan Wakely wrote:
This doesn't really belong in our testsuite, because the sole purpose of
the new test is to find bugs in the Glibc wrappers (like the one linked
below). But maybe it's a kindness to do it in our testsuite, because we
already have this test in place, and
On 2024-09-20 21:42, Siddhesh Poyarekar wrote:
On 2024-09-20 20:20, Sam James wrote:
Siddhesh Poyarekar writes:
This series makes a few improvements to get static object size
estimates in
more cases, thus improving the success rate of the static
__builtin_object_size. This should fully fix
On 2024-09-20 20:20, Sam James wrote:
Siddhesh Poyarekar writes:
This series makes a few improvements to get static object size estimates in
more cases, thus improving the success rate of the static
__builtin_object_size. This should fully fix PR116556 and also covers a bulk
of use cases for
): Likewise.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/builtin-object-size-1.c | 20 +++
gcc/testsuite/gcc.dg/builtin-object-size-3.c | 20 +++
gcc/tree-object-size.cc | 58
3 files changed, 86 insertions(+), 12 deletions(-)
diff
geLog:
PR middle-end/77608
* tree-object-size.cc (plus_stmt_object_size): Drop check for
constant offset.
* testsuite/gcc.dg/builtin-object-size-1.c (test14): New test.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/builtin-object-size-1.c
When wholesize != size, there is a reasonable opportunity for static
object sizes also to be computed using size_for_offset, so use that.
gcc/ChangeLog:
* tree-object-size.cc (plus_stmt_object_size): Call
SIZE_FOR_OFFSET for some negative offset cases.
* testsuite/gcc.dg/b
make-check did not introduce any new regressions
- i686 build and make-check did not introduce any new regressions
- Bootstrap build with bootstrap-ubsan config succeeded.
Thanks,
Sid
Siddhesh Poyarekar (4):
tree-object-size: use size_for_offset in more cases
tree-object-size: Fold PHI node
):
New functions.
(main): Call them.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/builtin-object-size-1.c | 63
gcc/testsuite/gcc.dg/builtin-object-size-3.c | 63
gcc/tree-object-size.cc | 60
On 2024-09-14 12:10, Andrew Pinski wrote:
+ /* Note that this is the *opposite* of what we usually do with sizes,
+because the maximum offset estimate here will give us a minimum size
+estimate and vice versa. */
+ enum tree_code code = (object_size_type & OST_MINIMUM
+
* tree-object-size.cc (try_collapsing_offset): New function.
(plus_stmt_object_size): Use it.
* gcc/testsuite/gcc.dg/builtin-object-size-1.c (test12): New
function.
(main): Call it.
Signed-off-by: Siddhesh Poyarekar
---
Tests underway for x86_64 and i686. OK if they
On 2024-09-08 18:01, Andrew Pinski wrote:
When I was implementing improvements into phiopt I ran into case where
objsz would fail now because we get:
tmp = PHI
ptr = ptr + tmp
where before the pointer plus was inside each branch instead. So my
question is there any progress on implementing objs
On 2024-07-26 13:11, Jakub Jelinek wrote:
On Thu, Jul 25, 2024 at 07:48:38PM -0400, Siddhesh Poyarekar wrote:
The code to scale ranges for wide chars in format_string incorrectly
checks range.likely to scale range.unlikely, which is a copy-paste typo
from the immediate previous condition.
gcc
chars.
Signed-off-by: Siddhesh Poyarekar
---
Tested on x86_64, no new testsuite regressions due to this fix.
gcc/gimple-ssa-sprintf.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gimple-ssa-sprintf.cc b/gcc/gimple-ssa-sprintf.cc
index 025b0fbff6f..0900710647c 100644
The inner loop in build_option_suggestions uses OPTION to take the
address of OPTB and use it across iterations, which is undefined
behaviour since OPTB is defined within the loop. Pull it outside the
loop to make this defined.
It's a trivial fix, so posting early. OK to commit once build and te
On 2024-04-25 10:06, Qing Zhao wrote:
gcc/testsuite/ChangeLog:
* c-c++-common/fam-in-union-alone-in-struct-1.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-2.c: New testcase.
* c-c++-common/fam-in-union-alone-in-struct-3.c: New testcase.
---
Sorry I should
On 2024-03-29 12:07, Qing Zhao wrote:
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible t
On 2024-03-29 12:07, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
On 2024-03-29 12:07, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/f
On 2024-03-18 12:28, Qing Zhao wrote:
This should probably bail out if object_size_type & OST_DYNAMIC == 0.
Okay. Will add this.
When add this into access_with_size_object_size, I found some old bugs
in early_object_sizes_execute_one, and fixed them as well.
Would you be able to isolate t
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.d
On 2024-02-16 14:47, Qing Zhao wrote:
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(buil
On 2024-02-16 14:47, Qing Zhao wrote:
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as th
On 2024-02-12 10:00, Richard Biener wrote:
GCC driver support is then to the extent identifying the inputs and the outputs.
We already have -MM to generate a list of non-system dependencies, so
gcc should be able to pass on inputs to the tool, which could then map
those files (and the system
On 2024-02-12 08:16, Martin Jambor wrote:
This probably ties in somewhat with an idea David Malcolm had riffed on
with me earlier, of caching files for diagnostics. If we could unify
file accesses somehow, we could make this happen, i.e. open/read files
as root and then do all execution as non-r
On 2024-02-09 15:06, Joseph Myers wrote:
Ideally dependencies would be properly set up so that everything is built
in the original build, and ideally there would be no need to relink at
install time (I'm not sure of the exact circumstances in which it might be
needed, or on what OSes to e.g. enco
On 2024-02-09 12:14, Joseph Myers wrote:
On Fri, 9 Feb 2024, Siddhesh Poyarekar wrote:
For privilege management we could add a --allow-root driver flag that allows
gcc to run as root. Without the flag one could either outright refuse to run
or drop privileges and run. Dropping privileges
On 2024-02-09 10:38, Martin Jambor wrote:
If anyone is interested in scoping this and then mentoring this as a
Google Summer of Code project this year then now is the right time to
speak up!
I can help with mentoring and reviews, although I'll need someone to
assist with actual approvals.
Th
On 2023-12-18 09:35, Siddhesh Poyarekar wrote:
The "exploitable vulnerability" may lead to a misunderstanding that
missed hardening issues are considered vulnerabilities, just that
they're not exploitable. This is not true, since while hardening bugs
may be security-relevant,
On 2023-12-20 00:23, Jeff Law wrote:
On 12/19/23 10:21, Siddhesh Poyarekar wrote:
Narrow down scope of the unknowns bitmap so that it is only accessible
within the reexamination process. This also removes any role of unknown
propagation from object_sizes_set, thus simplifying that code path
On 2023-12-19 17:57, Jakub Jelinek wrote:
On Mon, Dec 18, 2023 at 11:42:52AM -0500, Siddhesh Poyarekar wrote:
It is always safe to set the computed bit for dynamic object sizes at
the end of collect_object_sizes_for because even in case of a dependency
loop encountered in nested calls, we have
UNKNOWNS.
Drop all references to it.
(object_sizes_set): Move unknowns propagation code to...
(gimplify_size_expressions): ... here. Also free reexamine
bitmap.
(propagate_unknowns): New parameter UNKNOWNS. Update callers.
Signed-off-by: Siddhesh Poyarekar
/113012
* tree-object-size.cc (compute_builtin_object_size): Expand
comment for dynamic object sizes.
(collect_object_sizes_for): Always set COMPUTED bitmap for
dynamic object sizes.
Signed-off-by: Siddhesh Poyarekar
---
Testing:
- Bootstrapped x86_64 and config=ubsan
1 - 100 of 458 matches
Mail list logo
