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
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, the absence of hardening does not make a
program any more vulner
On 2023-12-07 10:42, Eric Botcazou wrote:
I think from a language standpoint, the general idea that nested
functions are just any functions inside functions (which is how the C
nested functions essentially behave) is too broad and they should be
restricted to minimal implementations that, e.g. do
On 2023-12-06 09:41, Jakub Jelinek wrote:
On Wed, Dec 06, 2023 at 09:30:32AM -0500, Siddhesh Poyarekar wrote:
We have the -Wmemset-transposed-args warning, couldn't we
have a similar one for calloc, and perhaps do it solely in
the case where one uses sizeof of the type used in the cast
po
On 2023-12-06 09:21, Jakub Jelinek wrote:
On Wed, Dec 06, 2023 at 02:34:10PM +0100, Martin Uecker wrote:
Further I think
"size less than or equal to the size requested"
is quite ambiguous in the calloc case, isn't the size requested in the
calloc case actually nmemb * size rather than just size?
On 2023-12-04 16:31, Martin Uecker wrote:
If (assuming from them being called lambdas) they are primarily for
small functions without side-effects then it's already a significantly
stronger specification than what we have right now with C nested
functions. That would end up enforcing what you de
On 2023-12-04 13:51, Jakub Jelinek wrote:
Why? The syntax doesn't seem to be something unexpected, and as C doesn't
have lambdas, one can use the nested functions instead.
The only problem is if you need to pass function pointers somewhere else
(and target doesn't have function descriptors or so
On 2023-12-04 13:48, Martin Uecker wrote:
I empathize with Jakub's stated use case though of keeping the C
frontend support for testing purposes, but that could easily be done
behind a flag, or by putting nested C func deprecation behind a flag.
I am relatively sure C will get some form of nest
[Branching this into a separate conversation to avoid derailing the
patch, which isn't directly related]
On 2023-12-04 12:21, Martin Uecker wrote:
I do not really agree with that. Nested functions can substantially
improve code quality and in C can avoid type unsafe use of
void* pointers in ca
On 2023-12-04 11:39, Andreas Schwab wrote:
On Dez 04 2023, Siddhesh Poyarekar wrote:
For hardened code in C, I think we really should look to step away from
nested functions instead of adding ways to continue supporting it. There's
probably a larger conversation to be had about the utili
On 2023-12-02 04:42, Martin Uecker wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
It came up that a good hardening strategy is to disable trampolines
which may require executable stack. Therefore the following patch
adds -Werror=trampolines to -fhardened.
This
On 2023-11-02 10:12, Martin Uecker wrote:
This shouldn't be necessary. The object-size pass
can track pointer arithmeti if it comes after
inserting the .ACCESS_WITH_SIZE.
https://godbolt.org/z/fvc3aoPfd
The problem is dependency tracking through the pointer arithmetic, which
Jakub suggested t
On 2023-10-31 12:26, Qing Zhao wrote:
Hi,
I wrote a summary based on our extensive discussion, hopefully this can be
served as an informal proposal.
Please take a look at it and let me know any comment or suggestion.
There are some (???) in the section 3.2 and 3.6, those are my questions seek
On 2023-10-28 16:29, Martin Uecker wrote:
Isn't this testcase h() in builtin-dynamic-object-size-20.c? If you're
referring to testcase i(), then maybe "where the size is given by a
non-trivial function of a function parameter, e.g.
fn (size_t n, char buf[dummy(n)])."
h() is supported. For i()
On 2023-10-26 04:37, Martin Uecker wrote:
Hi Sid and Jakub,
here is the patch discussed in PR 109334.
I can't approve, but here's a review:
Martin
tree-optimization/109334: Improve computation for access attribute
The fix for PR104970 restricted size computations to the
On 2023-10-25 09:27, Qing Zhao wrote:
On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote:
On 2023-10-24 18:51, Qing Zhao wrote:
Thanks for the proposal!
So what you suggested is:
For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the FE,
then the call to the _bdos
On 2023-10-25 04:16, Martin Uecker wrote:
Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener:
Am 24.10.2023 um 22:38 schrieb Martin Uecker :
Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
Hi, Sid,
Really appreciate for your example and detailed explanation. Ve
On 2023-10-24 18:51, Qing Zhao wrote:
Thanks for the proposal!
So what you suggested is:
For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the FE,
then the call to the _bdos (x.buf, 1) will
Become:
_bdos(__builtin_with_size(x.buf, x.L), 1)?
Then the implicit use of x.L
On 2023-10-24 18:41, Qing Zhao wrote:
On Oct 24, 2023, at 5:03 PM, Siddhesh Poyarekar wrote:
On 2023-10-24 16:30, Qing Zhao wrote:
Situation 2: With O0, the routine “get_size_from” was NOT inlined into “foo”,
therefore, the call to __bdos is Not in the same routine as the instantiation
On 2023-10-24 16:38, Martin Uecker wrote:
Here is another proposal: Add a new builtin function
__builtin_with_size(x, size)
that return x but behaves similar to an allocation
function in that BDOS can look at the size argument
to discover the size.
The FE insers this function when the field i
On 2023-10-24 16:30, Qing Zhao wrote:
Situation 2: With O0, the routine “get_size_from” was NOT inlined into “foo”,
therefore, the call to __bdos is Not in the same routine as the instantiation
of the object, As a result, the TYPE info and the attached counted_by info of
the object can NOT be
On 2023-10-23 15:43, Qing Zhao wrote:
On Oct 23, 2023, at 2:43 PM, Siddhesh Poyarekar wrote:
On 2023-10-23 14:06, Martin Uecker wrote:
We should aim for a good integration with the BDOS pass, so
that it can propagate the information further, e.g. the
following should work:
struct { int L
On 2023-10-23 14:06, Martin Uecker wrote:
We should aim for a good integration with the BDOS pass, so
that it can propagate the information further, e.g. the
following should work:
struct { int L; char buf[] __counted_by(L) } x;
x.L = N;
x.buf = ...;
char *p = &x->f;
__bdos(p) -> N
So we need t
On 2023-10-23 08:34, Richard Biener wrote:
A related issue is that assignment to the field and storage allocation
are not tied together - if there's no use of the size data we might
remove the store of it as dead.
Maybe the trick then is to treat the size data as volatile? That ought
to discou
On 2023-10-23 03:57, Richard Biener wrote:
On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote:
On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote:
On 2023-10-20 14:38, Qing Zhao wrote:
How about the following:
Add one more parameter to __builtin_dynamic_object_size(), i.e
On 2023-10-20 14:38, Qing Zhao wrote:
How about the following:
Add one more parameter to __builtin_dynamic_object_size(), i.e
__builtin_dynamic_object_size (_1,1,array_annotated->foo)?
When we see the structure field has counted_by attribute.
Or maybe add a barrier preventing any assignme
[Sorry, I forgot to respond to this]
On 2023-10-06 16:01, Martin Uecker wrote:
Am Freitag, dem 06.10.2023 um 06:50 -0400 schrieb Siddhesh Poyarekar:
On 2023-10-06 01:11, Martin Uecker wrote:
Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
On Thu, Oct 05, 2023 at 04:08:52PM
On 2023-10-18 10:51, Qing Zhao wrote:
+ member FIELD_DECL is a valid field of the containing structure's fieldlist,
+ FIELDLIST, Report error and remove this attribute when it's not. */
+static void
+verify_counted_by_attribute (tree fieldlist, tree field_decl)
+{
+ tree attr_counted_by =
On 2023-10-06 01:11, Martin Uecker wrote:
Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh Poyarekar wrote:
2. How would you handle signedness of the size field? The size gets
converted to sizetype everywhere it is used and
On 05-Oct-2023 18:35, Kees Cook wrote:On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh Poyarekar wrote:
> 2. How would you handle signedness of the size field? The size gets
> converted to sizetype everywhere it is used and overflows/underflows may
> produce interesting results
On 2023-08-25 11:24, Qing Zhao wrote:
This is the 3rd version of the patch, per our discussion based on the
review comments for the 1st and 2nd version, the major changes in this
version are:
Hi Qing,
I hope the review was helpful. Overall, a couple of things to consider:
1. How would you ha
On 2023-08-25 11:24, Qing Zhao wrote:
Use the counted_by atribute info in builtin object size to compute the
subobject size for flexible array members.
gcc/ChangeLog:
PR C/108896
* tree-object-size.cc (addr_object_size): Use the counted_by
attribute info.
* tr
On 2023-10-05 14:51, Siddhesh Poyarekar wrote:
On 2023-08-25 11:24, Qing Zhao wrote:
Provide a new counted_by attribute to flexible array member field.
The obligatory "I can't ack the patch but here's a review" disclaimer :)
'counted_by (COUNT)'
The
On 2023-08-25 11:24, Qing Zhao wrote:
Provide a new counted_by attribute to flexible array member field.
The obligatory "I can't ack the patch but here's a review" disclaimer :)
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the flexible array
member of a stru
Committed some trivial comma and indentation fixups that Jan shared with
me off-list.
Jan Engelhardt (2):
secpol: add grammatically missing commas / remove one excess instance
secpol: consistent indentation
SECURITY.txt | 48
1 file changed, 2
From: Jan Engelhardt
86% of the document have 4 spaces; adjust the remaining 14%.
Signed-off-by: Jan Engelhardt
ChangeLog:
* SECURITY.txt: Fix up indentation.
---
SECURITY.txt | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/SECUR
From: Jan Engelhardt
Signed-off-by: Jan Engelhardt
ChangeLog:
* SECURITY.txt: Fix up commas.
---
SECURITY.txt | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/SECURITY.txt b/SECURITY.txt
index b65f24cfc2a..93792923583 100644
--- a/SECURITY.txt
+++ b
On 2023-10-04 11:49, Alexander Monakov wrote:
On Thu, 28 Sep 2023, Siddhesh Poyarekar wrote:
Define a security process and exclusions to security issues for GCC and
all components it ships.
Some typos and wording suggestions below.
I've incorporated all your and David's sugge
1 - 100 of 421 matches
Mail list logo
