Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

>> >> Thanks, will file bugs and fix them first. > > I filed two bugs against GCC15: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119717 > > And assigned to myself. Both the above were resolved. Qing

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

Hi, Sid: > On Apr 10, 2025, at 06:56, Siddhesh Poyarekar wrote: > > >> Maybe you could add it when a pointer to an annotated >> struct is passed as parameter, but also there it is not >> clear to me that we might want to materialize new >> accesses to the struct at this point. >> An alternative

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 15, 2025, at 16:35, Kees Cook wrote: > > On Tue, Apr 15, 2025 at 09:07:44PM +0200, Martin Uecker wrote: >> Am Dienstag, dem 15.04.2025 um 14:50 +0200 schrieb Michael Matz: >>> Hello, >> ... >> struct A { int *buf __counted_by(len); // 'len' *must* be in the struct. in

Re: [PATCH v2] c: Fully fold each parameter for call to .ACCESS_WITH_SIZE [PR119717]

Thanks. Pushed to trunk. Qing > On Apr 15, 2025, at 14:56, Marek Polacek wrote: > > On Tue, Apr 15, 2025 at 06:46:26PM +0000, Qing Zhao wrote: >> This is the 2nd version of the patch, the change is to replace "FALSE" with >> "false" per Marek's

[PATCH v2] c: Fully fold each parameter for call to .ACCESS_WITH_SIZE [PR119717]

This is the 2nd version of the patch, the change is to replace "FALSE" with "false" per Marek's comments. C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold. In c_fully_fold, it assumes that operands of function calls have already been folded. However, when we build call to

Re: [PATCH] c: Fully fold each parameter for call to .ACCESS_WITH_SIZE [PR119717]

> On Apr 14, 2025, at 16:35, Marek Polacek wrote: > > On Mon, Apr 14, 2025 at 08:28:55PM +0000, Qing Zhao wrote: >> C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold. >> In c_fully_fold, it assumes that operands of function calls have already &g

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Hi, Bill, Thanks for your new proposal. If I understand correctly, this new proposal basically is back to one of our previous proposal: Adding a new structure scoping for counted_by attribute into C; With this approach, there is one new structure scoping added to C, and this new scope will

[PATCH] c: Fully fold each parameter for call to .ACCESS_WITH_SIZE [PR119717]

C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold. In c_fully_fold, it assumes that operands of function calls have already been folded. However, when we build call to .ACCESS_WITH_SIZE, all its operands are not fully folded. therefore the C FE specific operator is passed t

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 11, 2025, at 14:24, Martin Uecker wrote: > > Am Freitag, dem 11.04.2025 um 18:14 + schrieb Qing Zhao: >> >>> On Apr 11, 2025, at 13:37, Martin Uecker wrote: >>> >>> Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao: >>&g

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 11, 2025, at 14:12, Martin Uecker wrote: > > Am Freitag, dem 11.04.2025 um 13:55 -0400 schrieb Siddhesh Poyarekar: >> 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 >>>

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 11, 2025, at 13:55, Siddhesh Poyarekar wrote: > > 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 bo

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 11, 2025, at 13:37, Martin Uecker wrote: > > Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao: >> >>> On Apr 11, 2025, at 12:20, Martin Uecker wrote: >>> >>> Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao: >>&g

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 11, 2025, at 12:20, Martin Uecker wrote: > > Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao: >> >>> On Apr 11, 2025, at 10:53, Martin Uecker wrote: >>> >>> Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLe

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 11, 2025, at 10:53, Martin Uecker wrote: > > Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod: >> On 4/11/25 10:27, Qing Zhao wrote: >>> >>>> On Apr 10, 2025, at 11:12, Martin Uecker wrote: >>>> >>>> A

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 11, 2025, at 10:42, Andrew MacLeod wrote: > > > On 4/11/25 10:27, Qing Zhao wrote: >> >>> On Apr 10, 2025, at 11:12, Martin Uecker wrote: >>> >>> Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar: >>>>

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 10, 2025, at 10:55, Siddhesh Poyarekar wrote: > > 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

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 10, 2025, at 11:12, Martin Uecker wrote: > > Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar: >> 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

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 8, 2025, at 13:13, Siddhesh Poyarekar wrote: > > 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

[Stage 1][Middle-end][PATCH v5 0/3] Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

. fix PR117375 (Bug in tree-ssa-sink.cc); B. documentation clarification; C. Add all the duplicated PRs in the commit comments; 4. Bootstrap GCC with the new -fdiagnostics-details on by default (Init (1)). exposed some ICE similar as PR117375 in tree-ssa-sink.cc, fixed. Qing Zhao (3): Pr

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

> On Apr 10, 2025, at 15:22, Qing Zhao wrote: > > > >> On Apr 10, 2025, at 13:43, Martin Uecker wrote: >> >> Am Donnerstag, dem 10.04.2025 um 17:05 + schrieb Qing Zhao: >>> Hi, Martin, >>> >>> Thanks

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

> On Apr 10, 2025, at 13:43, Martin Uecker wrote: > > Am Donnerstag, dem 10.04.2025 um 17:05 + schrieb Qing Zhao: >> Hi, Martin, >> >> Thanks a lot for all your comments and questions, really helpful. >> >> > > ... >>> >>&g

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

> On Apr 7, 2025, at 22:15, Siddhesh Poyarekar wrote: > > 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: >>> >>>

Re: Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

Hi, Martin, Thanks a lot for all your comments and questions, really helpful. > On Apr 10, 2025, at 01:41, Martin Uecker wrote: > > Am Mittwoch, dem 09.04.2025 um 18:31 + schrieb Qing Zhao: >> Hi, Joseph and Martin, >> >> When I implemented the patch to attach

Questions on replacing a structure pointer reference to a call to .ACCESS_WITH_SIZE in C FE

Hi, Joseph and Martin, When I implemented the patch to attach the counted_by information to an array reference (FAM reference) in C FE, The work was done inside the routine “build_component_ref” in gcc/c/c-typeck.cc . and this is very reasonable and quite clean. Now, If

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 9, 2025, at 11:31, Siddhesh Poyarekar wrote: > > 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 >

Re: .ACCESS_WITH_SIZE and pointer ranges

> On Apr 8, 2025, at 21:13, Siddhesh Poyarekar wrote: > > 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

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

> On Apr 8, 2025, at 12:54, Siddhesh Poyarekar wrote: > > 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;

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

ny comment? Qing > On Apr 8, 2025, at 10:53, Qing Zhao wrote: > > > >> On Apr 7, 2025, at 22:15, Siddhesh Poyarekar wrote: >> >> On 2025-04-07 14:53, Qing Zhao wrote: >>>> Is there a reason to do this at the very end like this and

Re: [Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

> On Apr 7, 2025, at 13:43, Siddhesh Poyarekar wrote: > > 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 __coun

[Stage1][Middle-end][object-size][PATCH v1] Evaluate the object size by the size of the pointee type

when the type is a structure with flexible array member. In tree-object-size.cc, if the size is UNKNOWN after evaluating use-def chain, We can evaluate the SIZE of the pointee TYPE ONLY when this TYPE is a structure type with flexible array member, since a structure with FAM can not be an element

[Stage 1][Middle-end][PATCH v5 3/3] Provide more contexts for -Warray-bounds, -Wstringop-* warning messages due to code movements from compiler transformation (Part 3) [PR109071, PR85788, PR88771, PR1

[PR109071,PR85788,PR88771,PR106762,PR108770,PR115274,PR117179] Add debugging for move history. PR tree-optimization/109071 PR tree-optimization/85788 PR tree-optimization/88771 PR tree-optimization/106762 PR tree-optimization/108770 PR tree-optimiza

[Stage 1][Middle-end][PATCH v5 2/3] Provide more contexts for -Warray-bounds, -Wstringop-*warning messages due to code movements from compiler transformation (Part 2) [PR109071, PR85788, PR88771, PR10

size.to_uhwi (), ref.base, TREE_TYPE (ref.base))) - || warning_at (loc, opt, + || warning_at (&richloc, opt, form ? G_("%qD forming offset %s is out of "

[Stage 1][Middle-end][PATCH v5 1/3] Provide more contexts for -Warray-bounds, -Wstringop-*warning messages due to code movements from compiler transfromaton (Part 1) [PR109071, PR85788, PR88771, PR106

44 index 000..83d8a42b577 --- /dev/null +++ b/gcc/diagnostic-move-history.cc @@ -0,0 +1,265 @@ +/* Functions to handle move history. + Copyright (C) 2024 Free Software Foundation, Inc. + Contributed by Qing Zhao + + This file is part of GCC. + + GCC is free software; you can redistribu

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 7, 2025, at 10:31, Michael Matz wrote: > > Hello, > > On Mon, 7 Apr 2025, Martin Uecker wrote: > >>> So, what specifically would the two attributes do different? FWIW: what >>> worries me about accepting a generic expression in counted_by, that isn't >>> prefixed by a (possibly e

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 4, 2025, at 13:09, Martin Uecker wrote: > > Am Freitag, dem 04.04.2025 um 18:51 +0200 schrieb Michael Matz: >> Hello, >> >> On Fri, 4 Apr 2025, Qing Zhao wrote: >> >>> So, a different attribute name “counted_by_exp” might be better? >&g

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 4, 2025, at 12:51, Michael Matz wrote: > > Hello, > > On Fri, 4 Apr 2025, Qing Zhao wrote: > >> So, a different attribute name “counted_by_exp” might be better? > > I would prefer Martins empty-decl idea to that: "counted_by(;len+0)" >

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 4, 2025, at 12:40, Jakub Jelinek wrote: > > On Fri, Apr 04, 2025 at 04:25:11PM +0000, Qing Zhao wrote: >>> It is not just the parser, it is also the human reader who should be >>> able to clearly distinguish this (which is why I still prefer >>> d

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

So, a different attribute name “counted_by_exp” might be better? Qing > On Apr 4, 2025, at 11:55, Michael Matz wrote: > > Hello, > > On Fri, 4 Apr 2025, Qing Zhao wrote: > >> A: >> constexpr int len = 20; >> struct s { >> int len; >> int *

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 4, 2025, at 11:54, Martin Uecker wrote: > > Am Freitag, dem 04.04.2025 um 15:22 + schrieb Qing Zhao: >> Hi, Michael, >> >> Thanks a lot for raising these questions for the parser implementation of >> the new syntax. >> >> I sta

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Hi, Michael, Thanks a lot for raising these questions for the parser implementation of the new syntax. I started thinking about how to implement this new syntax inside counted_by attriubte In GCC C FE. Since I have very little experience with any parser, I do want to know any potential imple

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 4, 2025, at 04:59, Bill Wendling wrote: > > On Thu, Apr 3, 2025 at 9:54 AM Kees Cook wrote: >> On Wed, Apr 02, 2025 at 09:16:47PM +, Qing Zhao wrote: >>> Hi, Bill, >>> >>> Thanks for the summary. >>> >>> I think that

Re: Forward declaration

CC’ing gcc alias as well. Hi, Yeoul, I think the key for when to use the forward declaration syntax is: When there is only one single identifier as the argument of counted_by attribute, There will be no possibility of scope conflict between different identifiers inside the counted_by attrib

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Jakub, Thank you for the comments. > On Apr 2, 2025, at 02:48, Jakub Jelinek wrote: > > On Tue, Apr 01, 2025 at 05:13:46PM -0700, Bill Wendling wrote: >> On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker wrote: >>> Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zh

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 2, 2025, at 14:35, Bill Wendling wrote: > > On Tue, Apr 1, 2025 at 11:49 PM Jakub Jelinek wrote: >> On Tue, Apr 01, 2025 at 05:13:46PM -0700, Bill Wendling wrote: >>> On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker wrote: >>>> Am Dienstag, dem 01.04.2025 um

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 1, 2025, at 15:25, Martin Uecker wrote: > > Am Dienstag, dem 01.04.2025 um 18:58 + schrieb Qing Zhao: >> >>> On Apr 1, 2025, at 11:28, Martin Uecker wrote: >>> >>> Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao: >>&

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 1, 2025, at 11:28, Martin Uecker wrote: > > Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao: >> >>> On Apr 1, 2025, at 10:04, Martin Uecker wrote: >>> >>> >>> >>> Am Montag, dem 31.03.2025 um 13:59 -0700 sch

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Apr 1, 2025, at 10:04, Martin Uecker wrote: > > > > Am Montag, dem 31.03.2025 um 13:59 -0700 schrieb Bill Wendling: >>> I'd like to offer up this to solve the issues we're facing. This is a >>> combination of everything that's been discussed here (or at least that >>> I've been able to r

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Mar 28, 2025, at 08:51, Yeoul Na wrote: > > > >> On Mar 27, 2025, at 9:17 AM, Qing Zhao wrote: >> >> Yeoul, >> >> Thanks for the writeup. >> >> So, basically, This writeup insisted on introducing a new “structure scope” >>

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Yeoul, Thanks for the writeup. So, basically, This writeup insisted on introducing a new “structure scope” (similar as the instance scope in C++) into C language ONLY for counted_by attribute: 1. Inside counted_by attribute, the name lookup starts: A. Inside the current structure first (t

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Mar 13, 2025, at 12:29, Martin Uecker wrote: > > Am Donnerstag, dem 13.03.2025 um 15:41 + schrieb Qing Zhao: >> >>> On Mar 12, 2025, at 12:40, Martin Uecker wrote: >>> >>> Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao: >

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Mar 12, 2025, at 12:58, Joseph Myers wrote: > > On Wed, 12 Mar 2025, Martin Uecker wrote: > >> For a designator >> >> struct foo { int n; } a = { .n = 1 }; >> >> we also refer to a member 'n' of an instance 'a' of a structure type. >> The instance is simply implied by the context. >> >

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Mar 12, 2025, at 18:46, Yeoul Na wrote: > > > >> On Mar 12, 2025, at 3:40 PM, Bill Wendling wrote: >> >> On Wed, Mar 12, 2025 at 3:28 PM Yeoul Na wrote: On Mar 12, 2025, at 2:51 PM, John McCall wrote: On 12 Mar 2025, at 16:02, Bill Wendling wrote: > Qing pointed o

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Mar 12, 2025, at 12:40, Martin Uecker wrote: > > Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao: >> >>> On Mar 10, 2025, at 15:34, Martin Uecker wrote: >>> >>> Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall:

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

> On Mar 10, 2025, at 15:34, Martin Uecker wrote: > > Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall: >> > > ... > >> That said, my preference is still to just give preference to the field name, >> which sidesteps any need for disambiguation syntax and avoids this whole >> pro

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

Hi, Henrik, John, Sorry for my late reply to the thread. Before I wrote this proposal, I spent quite some time try to understand why people from C community and C++ community have so different views on the current syntax of counted_by. Then I spent some time to study and compare the variable

Re: [RFC][C]New syntax for the argument of counted_by attribute for C language

new syntax to the C standard. We’ll discuss how we address problems raised > here. Please see my inlined comments. > > Best, > Yeoul > > >> On Mar 6, 2025, at 2:03 PM, Yeoul Na wrote: >> >> + John & Félix & Patryk & Henrik >> >>&

[RFC][C]New syntax for the argument of counted_by attribute for C language

Hi, Since I sent the patch series for “extend counted_by attribute to pointer fields of structure” two months ago, a lot of discussion were invoked both in GCC community and CLANG community: https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673837.html https://discourse.llvm.org/t/rfc-enfor

Re: [PATCH] c: Assorted fixes for flexible array members in unions [PR119001]

Hi, Jakub, Thanks a lot for fixing this issues. Qing > On Feb 26, 2025, at 03:53, Jakub Jelinek wrote: > > Hi! > > r15-209 allowed flexible array members inside of unions, but as the > following testcase shows, not everything has been adjusted for that. > Unlike structures, in unions flexible

Re: [RFC][libgcc][PATCH] Fix two issues in libgcc/unwind-dw2-fde.c.

> On Feb 6, 2025, at 09:25, Richard Biener wrote: > > On Thu, Feb 6, 2025 at 2:57 PM Qing Zhao wrote: >> >> >> >>> On Feb 6, 2025, at 04:36, Richard Biener wrote: >>> >>> On Wed, Feb 5, 2025 at 4:40 PM Qing Zhao wrote: >>&g

Re: [RFC][libgcc][PATCH] Fix two issues in libgcc/unwind-dw2-fde.c.

> On Feb 6, 2025, at 04:36, Richard Biener wrote: > > On Wed, Feb 5, 2025 at 4:40 PM Qing Zhao wrote: >> >> >> >>> On Feb 5, 2025, at 07:46, Richard Biener wrote: >>> >>> On Tue, Feb 4, 2025 at 10:12 PM Qing Zhao wrote: >>>&

Re: [RFC][libgcc][PATCH] Fix two issues in libgcc/unwind-dw2-fde.c.

> On Feb 5, 2025, at 07:49, Jakub Jelinek wrote: > > On Wed, Feb 05, 2025 at 01:46:02PM +0100, Richard Biener wrote: >>> Please let me know any comments on this? >> >> I think I've seen this elsewhere -- the issue is the unwind register API does >> not allow for failures but I also think calli

Re: [RFC][libgcc][PATCH] Fix two issues in libgcc/unwind-dw2-fde.c.

> On Feb 5, 2025, at 07:46, Richard Biener wrote: > > On Tue, Feb 4, 2025 at 10:12 PM Qing Zhao wrote: >> >> Hi, >> >> One of our big application segv in libgcc code while unwinding the stack. >> >> This is a random crash while the applicat

[RFC][libgcc][PATCH] Fix two issues in libgcc/unwind-dw2-fde.c.

Hi, One of our big application segv in libgcc code while unwinding the stack. This is a random crash while the application throws a c++ exception and unwinds the stack. Incidents are random and never can be reproduced by any test case. The libgcc that is used is based on GCC 8. Fortunately, we

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Hi, Bill, Sorry for the late reply (just be back from a short vacation). > On Jan 23, 2025, at 17:44, Bill Wendling wrote: > > On Fri, Jan 17, 2025 at 8:20 AM Qing Zhao wrote: >> >> Hi, Bill, >> >> Thanks a lot for your testing case. >> >> I s

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

> On Jan 23, 2025, at 13:27, Martin Uecker wrote: > > Am Donnerstag, dem 23.01.2025 um 17:39 + schrieb Qing Zhao: >> >>> On Jan 22, 2025, at 12:20, Martin Uecker wrote: >>> >>> Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker:

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

> On Jan 22, 2025, at 12:20, Martin Uecker wrote: > > Am Mittwoch, dem 22.01.2025 um 18:11 +0100 schrieb Martin Uecker: >> Am Mittwoch, dem 22.01.2025 um 16:37 +0000 schrieb Qing Zhao: >>> >>>> On Jan 22, 2025, at 11:22, Martin Uecker wrote: >>&

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

> On Jan 22, 2025, at 11:22, Martin Uecker wrote: > > > Hello Michael, > > Am Mittwoch, dem 22.01.2025 um 16:54 +0100 schrieb Michael Matz: >> On Wed, 22 Jan 2025, Martin Uecker wrote: >> > So you do not need to look further. But maybe I am missing something > else. Lik

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

> On Jan 20, 2025, at 16:19, Joseph Myers wrote: > > On Sat, 18 Jan 2025, Kees Cook wrote: > >> Gaining access to global variables is another gap Linux has -- e.g. we >> have arrays that are sized by the global number-of-cpus variable. :) > > Note that it's already defined that counted_by ta

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

> On Jan 17, 2025, at 18:13, Joseph Myers wrote: > > On Fri, 17 Jan 2025, Qing Zhao wrote: > >> struct fc_bulk { >> ... >> struct fs_bulk fs_bulk; >> struct fc fcs[] __counted_by(fs_bulk.len); >> }; >> >> i.e, the “counted_by” field

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

src/gcc/builtins.cc:10838 > 0xb6a5be fold_builtin_n > ../../gcc.src/gcc/builtins.cc:10950 > 0x1203910 dynamic_object_sizes_execute_one > ../../gcc.src/gcc/tree-object-size.cc:2187 > 0x1203910 object_sizes_execute > ../../gcc.src/gcc/tree-object-size.cc:2250 > Please submit

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

Joseph, Kees and Bill, I need your input on this. > On Jan 17, 2025, at 10:12, Martin Uecker wrote: > > Am Donnerstag, dem 16.01.2025 um 21:18 + schrieb Qing Zhao: >> > .. >> >> Although in the previous discussion, I agreed with Martin that we should us

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

> On Jan 16, 2025, at 17:29, Bill Wendling wrote: > > On Thu, Jan 16, 2025 at 1:19 PM Qing Zhao wrote: >> >> Hi, >> >> This is the patch set to extend "counted_by" attribute to pointer fields of >> structures. >> >> For e

[GCC16 stage 1][RFC][C][PATCH 3/3] Use the counted_by attribute of pointers in array bound checker.

Current array bound checker only instruments ARRAY_REF, and the INDEX information is the 2nd operand of the ARRAY_REF. When extending the array bound checker to pointer references with counted_by attributes, the hardest part is to get the INDEX of the corresponding array ref from the offset comput

[GCC16 stage 1][RFC][PATCH 2/3] Convert a pointer reference with counted_by attribute to .ACCESS_WITH_SIZE and use it in builtinin-object-size.

gcc/c/ChangeLog: * c-typeck.cc (build_counted_by_ref): Handle pointers with counted_by. (build_access_with_size_for_counted_by): Likewise. gcc/ChangeLog: * tree-object-size.cc (access_with_size_object_size): Handle pointers with counted_by. (collect_object

[GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

ound checker to pointer references with counted_by attributes, the hardest part is to get the INDEX of the corresponding array ref from the offset computation expression of the pointer ref. The whole patch set has been bootstrapped and regression tested on both aarch64 and x86. Let

[GCC16 stage 1][RFC][C][PATCH 1/3] Extend "counted_by" attribute to pointer fields of structures.

For example: struct PP { size_t count2; char other1; char *array2 __attribute__ ((counted_by (count2))); int other2; } *pp; specifies that the "array2" is an array that is pointed by the pointer field, and its number of elements is given by the field "count2" in the same structure. gcc/c

5th Ping: [Middle-end][PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

loop unrolling)? B. If not, how to improve the current design to make it more extendable? C. If yes, whether it’s okay to add this patches into GCC15, and then improve it in GCC16? Thanks. Qing > On Dec 23, 2024, at 12:29, Qing Zhao wrote: > > Hi, > > This is the 4th pin

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 10, 2025, at 15:34, Jeff Law wrote: > > > > On 1/9/25 1:39 PM, Qing Zhao wrote: >>> On Jan 9, 2025, at 14:10, Jeff Law wrote: >>> >>> >>> >>> On 1/9/25 10:48 AM, Qing Zhao wrote: >>> >>>>&g

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 10, 2025, at 10:05, Richard Biener wrote: > > On Fri, Jan 10, 2025 at 3:27 PM Qing Zhao wrote: >> >> >> >>> On Jan 10, 2025, at 03:00, Richard Biener >>> wrote: >>> >>> On Thu, Jan 9, 2025 at 9:39 PM Qing Zhao wr

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 10, 2025, at 03:00, Richard Biener wrote: > > On Thu, Jan 9, 2025 at 9:39 PM Qing Zhao wrote: >> >> >> >>> On Jan 9, 2025, at 14:10, Jeff Law wrote: >>> >>> >>> >>> On 1/9/25 10:48 AM, Qing Zhao wrote:

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 9, 2025, at 14:10, Jeff Law wrote: > > > > On 1/9/25 10:48 AM, Qing Zhao wrote: > >>> >>> I think Jeff's patch is not reasonable since it boils down to not diagnose >>> -Warray-bounds but instead remove those stmts. >> If

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 9, 2025, at 03:17, Sam James wrote: > > Richard Biener writes: > >> On Wed, Jan 8, 2025 at 5:34 PM Qing Zhao wrote: >>> >>> >>> >>>> On Jan 7, 2025, at 07:29, Richard Biener >>>> wrote: >>>> >

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 9, 2025, at 03:08, Richard Biener wrote: > > On Wed, Jan 8, 2025 at 5:34 PM Qing Zhao wrote: >> >> >> >>> On Jan 7, 2025, at 07:29, Richard Biener wrote: >>> >>> On Mon, Jan 6, 2025 at 5:40 PM Qing Zhao wrote: >>&g

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 7, 2025, at 07:29, Richard Biener wrote: > > On Mon, Jan 6, 2025 at 5:40 PM Qing Zhao wrote: >> >> >> >>> On Jan 6, 2025, at 11:01, Richard Biener wrote: >>> >>> On Mon, Jan 6, 2025 at 3:43 PM Qing Zhao wrote: >>>

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 6, 2025, at 11:01, Richard Biener wrote: > > On Mon, Jan 6, 2025 at 3:43 PM Qing Zhao wrote: >> >> >> >>> On Jan 6, 2025, at 09:21, Jeff Law wrote: >>> >>> >>> >>> On 1/6/25 7:11 AM, Qing Zhao wrote: >&

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 6, 2025, at 09:21, Jeff Law wrote: > > > > On 1/6/25 7:11 AM, Qing Zhao wrote: >>> >>> Given it doesn't cause user visible UB, we could insert the trap *before* >>> the UB inducing statement. That would then make the statement unr

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 4, 2025, at 12:58, Jeff Law wrote: > > > > On 1/3/25 10:30 AM, Qing Zhao wrote: >>> On Jan 3, 2025, at 11:41, Richard Biener wrote: >>> >>> >>> >>>> Am 03.01.2025 um 16:22 schrieb Jeff Law : >>>>

Re: [RFC/RFA] [PR tree-optimization/92539] Improve code and avoid Warray-bounds false positive

> On Jan 3, 2025, at 11:41, Richard Biener wrote: > > > >> Am 03.01.2025 um 16:22 schrieb Jeff Law : >> >> So this is an implementation of an idea I had a few years back and >> prototyped last spring to fix pr92539. >> >> pr92539 is a false positive Warray-bounds warning triggered by loop

4th Ping: [Middle-end][PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

messages Date: December 6, 2024 at 13:32:55 EST To: Qing Zhao , Jeff Law Cc: richard Biener , GCC Patches , kees Cook , Andrew Pinski , David Malcolm Qing Zhao writes: This is the 3rd ping of the Middle-end review for this patch. Jeff, would you be able to take a look? (In part because I know

Re: [PATCH] c: do not warn about truncating NUL char when initializing nonstring arrays [PR117178]

Hi, Kees, (Sorry for the late reply, I was on vacation last week). I read all the comments of PR117178 and also your patch. Yes, I think the behavior of this patch is reasonable. The updated diagnostic messages are more accurate and helpful. And the testing cases look good. I am wondering wh

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

> On Dec 12, 2024, at 17:36, Martin Uecker wrote: > > Am Donnerstag, dem 12.12.2024 um 13:59 -0800 schrieb Bill Wendling: >> >> >> So, it’s the correct behavior for the counted_by attribute for FAM based >> on our previous discussion and agreement. > > If it is indee

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

> On Dec 7, 2024, at 03:57, Martin Uecker wrote: > > Am Freitag, dem 06.12.2024 um 16:13 + schrieb Qing Zhao: >> >>> On Dec 6, 2024, at 10:56, Martin Uecker wrote: >>> >>> Am Freitag, dem 06.12.2024 um 14:16 + schrieb Qing Zhao: >>&

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

> On Dec 6, 2024, at 10:56, Martin Uecker wrote: > > Am Freitag, dem 06.12.2024 um 14:16 + schrieb Qing Zhao: >> >>> On Dec 5, 2024, at 17:31, Martin Uecker wrote: >>> >>> Am Donnerstag, dem 05.12.2024 um 21:09 + schrieb Qing Zhao: >&

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

> On Dec 5, 2024, at 17:31, Martin Uecker wrote: > > Am Donnerstag, dem 05.12.2024 um 21:09 + schrieb Qing Zhao: >> >>> On Dec 3, 2024, at 10:29, Qing Zhao wrote: > > > >>>> >>>>>> >>>>>>>>

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

> On Dec 3, 2024, at 10:29, Qing Zhao wrote: > > > >> On Dec 3, 2024, at 10:07, Martin Uecker wrote: >> >> Am Dienstag, dem 03.12.2024 um 14:31 + schrieb Qing Zhao: >>> >>>> On Dec 3, 2024, at 01:33, Martin Uecker wrote: >>

3rd Ping: [Middle-end][PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

This is the 3rd ping of the Middle-end review for this patch. Thanks a lot! Qing > On Nov 26, 2024, at 10:30, Qing Zhao wrote: > > Another ping on the Middle-end review of this patch. > > This patch has been waiting for the middle-end review for a long time. > >

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

> On Dec 3, 2024, at 10:07, Martin Uecker wrote: > > Am Dienstag, dem 03.12.2024 um 14:31 + schrieb Qing Zhao: >> >>> On Dec 3, 2024, at 01:33, Martin Uecker wrote: >>> >>> Am Montag, dem 02.12.2024 um 22:58 + schrieb Qing Zhao: >>&

Re: Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

> On Dec 3, 2024, at 01:25, Martin Uecker wrote: > > Am Montag, dem 02.12.2024 um 22:33 + schrieb Qing Zhao: > > > >>>> >>>> diff --git a/gcc/testsuite/gcc.dg/pr114014.c >>>> b/gcc/testsuite/gcc.dg/pr114014.c >>

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

> On Dec 3, 2024, at 01:33, Martin Uecker wrote: > > Am Montag, dem 02.12.2024 um 22:58 + schrieb Qing Zhao: >> >>> On Dec 2, 2024, at 16:13, Martin Uecker wrote: >>> >>> Am Montag, dem 02.12.2024 um 20:15 + schrieb Qing Zhao: >>&g

Re: Should -fsanitize=bounds support counted-by attribute for pointers inside a structure?

> On Dec 2, 2024, at 16:13, Martin Uecker wrote: > > Am Montag, dem 02.12.2024 um 20:15 + schrieb Qing Zhao: >> >>> On Nov 30, 2024, at 07:22, Martin Uecker wrote: >>> >>> Am Dienstag, dem 26.11.2024 um 20:59 + schrieb Qing Zhao: >&

  1   2   3   4   5   6   7   8   9   10   >