Ping!
On 2023-09-28 07:55, Siddhesh Poyarekar wrote:
Define a security process and exclusions to security issues for GCC and
all components it ships.
Signed-off-by: Siddhesh Poyarekar
---
SECURITY.txt | 205 +++
1 file changed, 205 insertions
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
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
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
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
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:
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-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 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-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 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 =
[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
18-07-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-collision-avoidance.c: New file.
* config.gcc (extra_objs): Build it.
* config/aarch64/t-aarch64 (falkor-tag-collision-avoidance.o):
Likewise.
* config/aarch64/aa
On 07/02/2018 03:29 PM, Kyrill Tkachov wrote:
Nice! What were the regressions though? Would be nice to adjust the tests
to make them more robust so that we have as clean a testsuite as possible.
Sure, they're gcc.dg/guality/pr36728-2.c and gcc.target/aarch64/extend.c.
The addressing mode costs
yrill
- Avoid renaming R0/V0 since they could be return values
- Fixed minor formatting issues.
2018-07-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-collision-avoidance.c: New file.
* config.gcc (extra_objs): Build it.
* config/aa
On 07/13/2018 06:32 PM, Kyrill Tkachov wrote:
This looks good to me modulo a couple of minor comments inline.
You'll still need an approval from a maintainer.
Thanks, I'll send a fixed up version on Monday.
+ for (ause= DF_REG_USE_CHAIN (regno); ause; ause = DF_REF_NEXT_REG
(ause))
+ {
that falkor does not support sve
Changes from v1:
- Fixed up issues pointed out by Kyrill
- Avoid renaming R0/V0 since they could be return values
- Fixed minor formatting issues.
2018-07-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-coll
On 07/16/2018 09:59 PM, Kyrill Tkachov wrote:
I think this looks ok now. You'll still need a maintainer to approve it
though.
Thank you for the review Kyrill, but also apologies for wasting your
time on it. I just found that the patch breaks a test so I'm currently
reviewing it to see what's
aming R0/V0 since they could be return values
- Fixed minor formatting issues.
2018-07-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-collision-avoidance.c: New file.
* config.gcc (extra_objs): Build it.
* config/aarch64/t-aa
Hello,
Ping!
On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote:
Hi,
This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February.
The falkor hardware prefetching system uses a combination of the
source, destination and offset to decide
/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-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
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 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 co
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 t
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 __builtin_object_size(p->a,0)
On 2023-08-01 18:57, Kees Cook wrote:
return p;
}
/* in the following function, malloc allocated less space than size of the
struct fix. Then what's the correct behavior we expect
the __builtin_object_size should have for the following?
*/
static struct fix * noinline alloc_buf_l
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 is
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 to
On 2023-08-02 10:02, Qing Zhao wrote:
/*when checking the observed access p->array, we only have info on the
observed access, i.e, the TYPE_SIZE info from the access. We don't have
info on the whole object. */
expect(__builtin_dynamic_object_size(q->array, 1), q->foo * sizeof(int
On 2023-08-03 12:43, Qing Zhao wrote:
Surely we could emit that for __bdos(q->array, 0) though, couldn't we?
For __bdos(q->array, 0), we only have the access info for the sub-object q->array,
we can surely decide the size of the sub-object q->array, but we still cannot
decide the whole objec
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular fixed size
array in the structure,
We have this same issue, for example:
#define LENGTH 10
struct fix {
size_t foo;
int array[LENGTH];
};
…
int main ()
{
struct fix *p;
p = al
On 2023-08-04 10:40, Siddhesh Poyarekar wrote:
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular
fixed size array in the structure,
We have this same issue, for example:
#define LENGTH 10
struct fix {
size_t foo;
int array[LENGTH
On 2023-08-04 11:27, Qing Zhao wrote:
On Aug 4, 2023, at 10:40 AM, Siddhesh Poyarekar wrote:
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular fixed size
array in the structure,
We have this same issue, for example:
#define LENGTH 10
On 2023-08-04 15:06, Qing Zhao wrote:
Yes, that's what I'm thinking.
so `q` must be pointing to a single element. So you could deduce:
1. the minimum size of the whole object that q points to.
You mean that the TYPE will determine the minimum size of the whole object?
(Does this include th
On 2023-08-08 04:16, Richard Biener wrote:
On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches
wrote:
FOSS Best Practices recommends that projects have an official Security
policy stated in a SECURITY.md or SECURITY.txt file at the root of the
repository. GLIBC and Binutils have add
On 2023-08-08 10:04, Richard Biener wrote:
On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor wrote:
On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches
wrote:
On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches wrote:
There's probably external tools to do this,
On 2023-08-08 10:14, David Edelsohn wrote:
On Tue, Aug 8, 2023 at 10:07 AM Siddhesh Poyarekar <mailto:siddh...@gotplt.org>> wrote:
On 2023-08-08 10:04, Richard Biener wrote:
> On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor mailto:i...@google.com>> wrote:
>&g
On 2023-08-08 10:37, Jakub Jelinek wrote:
On Tue, Aug 08, 2023 at 10:30:10AM -0400, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc, libstdc++,
etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
BTW, I think we s
On 2023-08-08 11:48, David Malcolm wrote:
On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote:
On Aug 8, 2023, at 9:01 AM, Jakub Jelinek via Gcc-patches
wrote:
On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-
patches wrote:
There's probably external tools
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc,
libstdc++, etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
Hi David,
Here's what I came up with for different parts of GCC, including th
On 2023-08-09 14:17, David Edelsohn wrote:
On Wed, Aug 9, 2023 at 1:33 PM Siddhesh Poyarekar <mailto:siddh...@gotplt.org>> wrote:
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
>> Do you have a suggestion for the language to address libgcc,
>> libstdc+
On 2023-08-10 10:47, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 16:42 +0200 schrieb Jakub Jelinek:
On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 13:59 + schrieb Qing Zhao:
On Aug 10, 2023, at 2:58 AM, Martin Uecker wrote:
Am
On 2023-08-10 11:18, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 10:58 -0400 schrieb Siddhesh Poyarekar:
On 2023-08-10 10:47, Martin Uecker wrote:
Am Donnerstag, dem 10.08.2023 um 16:42 +0200 schrieb Jakub Jelinek:
On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
Am
On 2023-08-10 12:39, Jakub Jelinek wrote:
On Thu, Aug 10, 2023 at 12:30:06PM -0400, Siddhesh Poyarekar wrote:
The definition of __bos/__bdos allows us the freedom to *estimate* rather
than be precise, so I'd go for sizeof(x) + N * sizeof(*x.a) since it's bound
to give the more co
On 2023-08-10 14:28, Richard Sandiford wrote:
Siddhesh Poyarekar writes:
On 2023-08-08 10:30, Siddhesh Poyarekar wrote:
Do you have a suggestion for the language to address libgcc,
libstdc++, etc. and libiberty, libbacktrace, etc.?
I'll work on this a bit and share a draft.
Hi
On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
valid input source code.
I think this leaves open the interpretation "every wrong code b
On 2023-08-11 11:09, Paul Koning wrote:
On Aug 11, 2023, at 10:36 AM, Siddhesh Poyarekar wrote:
On 2023-08-10 14:50, Siddhesh Poyarekar wrote:
As a result, the only case for a potential security issue in all
these cases is when it ends up generating vulnerable output for
On 2023-08-11 11:12, David Edelsohn wrote:
The text above states "bugs in these libraries may be evaluated for
security impact", but there is no comment about the criteria for a
security impact, unlike the GLIBC SECURITY.md document. The text seems
to imply the "What is a security bug?" defini
Hi,
Here's the updated draft of the top part of the security policy with all
of the recommendations incorporated.
Thanks,
Sid
What is a GCC security bug?
===
A security bug is one that threatens the security of a system or
network, or might compromise the sec
On 2023-08-14 14:51, Richard Sandiford wrote:
I think it would help to clarify what the aim of the security policy is.
Specifically:
(1) What service do we want to provide to users by classifying one thing
as a security bug and another thing as not a security bug?
(2) What service do we wa
On 2023-08-14 17:16, Alexander Monakov wrote:
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
1. It makes it clear to users of the project the scope in which the project
could be used and what safety it could reasonably expect from the project. In
the context of GCC for example, it cannot
On 2023-08-15 01:59, Alexander Monakov wrote:
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
There's no practical (programmatic) way to do such validation; it has to be a
manual audit, which is why source code passed to the compiler has to be
*trusted*.
No, I do not think that is a lo
On 2023-08-14 19:12, Qing Zhao wrote:
Hi, Sid,
For the following testing case:
#include
#define noinline __attribute__((__noinline__))
static void noinline alloc_buf_more (int index)
{
struct annotated {
long foo;
char b;
char array[index];
long c;
} q, *p;
p =
On 2023-08-15 10:07, Alexander Monakov wrote:
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
Does this as the first paragraph address your concerns:
Thanks, this is nicer (see notes below). My main concern is that we shouldn't
pretend there's some method of verifying that arbitr
On 2023-08-16 04:25, Alexander Monakov wrote:
On Tue, 15 Aug 2023, David Malcolm via Gcc-patches wrote:
I'd prefer to reword this, as libgccjit was a poor choice of name for
the library (sorry!), to make it clearer it can be used for both ahead-
of-time and just-in-time compilation, and that a
On 2023-08-15 19:07, Alexander Monakov wrote:
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
Thanks, this is nicer (see notes below). My main concern is that we
shouldn't pretend there's some method of verifying that arbitrary source
code is "safe" to pass to an unsan
On 2023-08-16 11:06, Alexander Monakov wrote:
No I understood the distinction you're trying to make, I just wanted to point
out that the effect isn't all that different. The intent of the wording is
not to prescribe a solution, but to describe what the compiler cannot do and
hence, users must fi
On 2023-08-16 11:59, Qing Zhao wrote:
Jakub and Sid,
During my study, I found an interesting behavior for the following small
testing case:
#include
#include
struct fixed {
size_t foo;
char b;
char array[10];
} q = {};
#define noinline __attribute__((__noinline__))
static void no
On 2023-08-17 09:58, Qing Zhao wrote:
So this is a (sort of) known issue, which necessitated the early_objsz pass to
get an estimate before a subobject reference was optimized to a MEM_REF.
Do you mean that after a subobject reference was optimized to a MEM_REF, there
is no way to compute the
On 2023-08-17 15:27, Qing Zhao wrote:
Yes, that's it. Maybe it's more correct if instead of MAX_EXPR if for
OST_MINIMUM we stick with the early_objsz answer if it's non-zero. I'm not
sure if that's the case for maximum size though, my gut says it isn't.
So, the major purpose for adding the
On 2023-08-17 16:23, Qing Zhao wrote:
Then, I think whatever MIN or MAX, the early phase has more precise information
than the later phase, we should use its result if it’s NOT UNKNOWN?
We can't be sure about that though, can we? For example for something like
this:
struct S
{
int a;
ch
On 2023-08-17 17:25, Qing Zhao wrote:
It's not exactly the same issue, the earlier discussion was about choosing sizes in the
same pass while the current one is about choosing between passes, but I agree it
"rhymes". This is what I was alluding to originally (for OST_MINIMUM use
MIN_EXPR if b
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
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-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 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 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-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-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 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 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-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-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-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-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-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-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
-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-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 al
On 8/25/21 5:44 PM, Matthias Klose wrote:
On 7/28/21 1:44 PM, David Malcolm via Gcc-patches wrote:
On Wed, 2021-07-28 at 10:34 +0530, Siddhesh Poyarekar wrote:
Recognize __builtin_free as being equivalent to free when passed into
__attribute__((malloc ())), similar to how it is treated when it
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
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
gcc.dg/attr-nonstring-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-wa
/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
(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 Poya
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
o
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 l
(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 and
-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
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
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 | return
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
:
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 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 st
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), a
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 @@ a
/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
On 11/19/21 21:48, Jakub Jelinek wrote:
On Wed, Nov 10, 2021 at 12:31:28AM +0530, Siddhesh Poyarekar wrote:
Put all accesses to object_sizes behind functions so that we can add
dynamic capability more easily.
gcc/ChangeLog:
* tree-object-size.c (object_sizes_grow, object_sizes_release
1 - 100 of 421 matches
Mail list logo
